Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

Archive for the ‘Foundation’ Category

K8s at the Edge – Some Context on the New Kubernetes IoT Working Group

It’s hard to believe that Google released Kubernetes as an open source project only three years ago. What began as the Borg cluster management platform to provide services like Gmail and YouTube at global scale is now the standard orchestration layer at the center of a massive industry shift to cloud native.

Enterprises are being catapulted into system resource engineering concepts that have been the bedrock of operations at web-scale leaders like Google and Netflix, and the open source stack underneath it all is evolving so fast it’s hard to keep up.  Kubernetes is attracting all sorts of exciting frameworks and services (see projects like Istio and Envoy), and no one could have anticipated it having this degree of momentum.

So what does any of this have to do with IoT?

The Eclipse Foundation is excited to be part of today’s announcement of a new Kubernetes IoT Edge Working Group – in conjunction with CNCF and supported by leading vendors like Bosch, Eurotech, InfluxData, Red Hat, Siemens, Vapor IO, and VMware.  

Eclipse Foundation has a lot on the go with IoT — 2.93 million lines of code (by last count), 42 different member organizations, 36 projects and 280 developers. The pace of innovation in IoT is very fast, and there are still a lot of great unsolved challenges at the IoT Edge.

Kubernetes was born in the datacenter. Its original promise was bridging datacenter and cloud.

But Kubernetes has a ton of potential for handling massive workloads on the edge — providing a common control plane across hybrid cloud and edge environments to simplify management and operations. Chick-fil-A, for example, is running Kubernetes at the edge in every restaurant.

Some of the great unsolved problems at the IoT edge — connectivity, manageability, scalability, reliability, security challenges, how to bring compute resources closer to edge devices for faster data processing and actions — are being solved as one-offs by the enterprises that are jumping into IoT. This new working group sees Kubernetes as having great potential as a foundational technology for extending hybrid environments to the IoT edge, and believes that broader industry collaboration on requirements definition around Kubernetes will accelerate broader adoption of IoT. Once again, it’s the rising tide theory of open source.

As Red Hat’s Dejan Bosanac (lead for the Kubernetes IoT Edge Working Group) says:

“IoT and edge applications have many distributed components that don’t usually sit together within the same datacenter infrastructure. There are messaging challenges, security has to be re-invented for every application and service, and there are integration and data locality issues with sidecar services. These are issues that shouldn’t have to be re-invented every time — they should be open source infrastructure with broad industry support. Red Hat and this working group see Kubernetes and other cloud-native projects in its orbit as having broad potential sitting between gateways, edge nodes and cloud platforms. Much like the LAMP stack was instrumental to the web-applications era, this group is focused on accelerating a Kubernetes stack for running cloud infrastructure and distributed components at the IoT edge.”

Some of the initial targets for the group in how it evolves Kubernetes for IoT edge applications:

  • Supporting Industrial IoT (IIoT) use cases scaling to millions of constrained devices a) connecting directly to Kubernetes-based cloud infrastructure (IP enabled devices), or b) connecting via IoT gateways (for non-IP enabled devices)
  • Via Edge nodes, bringing computing closer to data sources to support processing and acting on data sooner. Anticipated benefits include reduced latency, lower bandwidth, and improved reliability. Some example use cases:
    • Deploying data streaming applications to the Edge nodes in order to reduce traffic and save bandwidth between devices and the central cloud.
    • Deploying a serverless framework for using local functions that can be triggered as a response to certain events (without communication with the cloud)
  • Providing a common control plane across hybrid cloud and edge environments to simplify management and operations

The initial focus of the working group will be to flesh out IoT edge computing use cases and see how Kubernetes can be used (and to what extent). Among some of  the requirements identified so far:

  • For IIoT applications, the Kubernetes ingress layer must scale to millions of connections
  • That same ingestion layer must provide first-class support for IIoT messaging protocols such as MQTT (it is primarily HTTP TLS centric today)
  • Kubernetes must support multi-tenancy for environments where devices and gateways are shared

There have been a lot of industry watchers who have been wondering aloud how high the ceiling is for Kubernetes. Container orchestration seems like such a specific technology – how can this technology reach this type of ubiquity? Well one thing is clear – Kubernetes has jumped the datacenter and is now clearly in play in IoT ($1.2T market by 2022, according to IDC) as well. We are excited to be collaborating with the Kubernetes community to enable next generation of IoT applications.

To learn more, head over to the Kubernetes IoT Edge Working Group community page.

Have specific ideas for how you’d like to see Kubernetes evolve to meet your IoT use cases? Check out the this working document where you can get a sense of the progress so far, and the areas where you could possibly contribute your talents.

Written by Mike Milinkovich

September 26, 2018 at 7:00 am

Posted in Foundation, Open Source

Jakarta EE Progress to Date

Last September Oracle announced, with the support of IBM and Red Hat, that Java EE was going to move to the Eclipse Foundation. Since then Fujitsu, Payara and Tomitribe have all joined the initiative with strategic-level commitments. The scale of this migration is huge, and if you’re interested in understanding the complexity of the undertaking, I highly recommend you read On Complexity and Good Intentions.

Roughly eight months later, let’s see how we are doing compared to the goals set out in Oracle’s original announcement.

  • Relicense Oracle-led Java EE technologies, and related GlassFish technologies, to the Foundation. This would include RIs, TCKs, and associated project documentation.

This has been the major accomplishment to date. The Eclipse Enterprise for Java (EE4J) top-level project has been created, and thirty-nine projects established. We don’t yet have all of the source code moved over, but you can follow the steady progress on the project status page. All of the projects are using the same license: Eclipse Public License 2.0 plus (Secondary) GNU General Public License, version 2 with the GNU Classpath Exception.

  • Demonstrate the ability to build a compatible implementation, using Foundation sources, that passes existing Java EE 8 TCKs.

This is what the project community is working towards next, and it is going to be a Very Big Deal. Keep in mind that to accomplish this goal, we are going to have to complete the creation of 39 projects, get them building on eclipse.org infrastructure, run the Java EE 8 CTS on those builds, and then get all of the projects together to ship on the same day. There is an enormous amount of work and learning to be done before this release becomes a reality.
 

  • Define a branding strategy for the platform within the Foundation, including a new name for Java EE to be determined. We intend to enable use of existing javax package names and component specification names for existing JSRs to provide continuity.

In the first quarter of 2018, the Eclipse Foundation worked with the community to establish a new name and a logo for the future of this technology. So Jakarta EE was born, and we’re very excited about the new name and the logo. Folks who have been around the Java world for a long time will recognize the name “Jakarta,” as the Apache Software Foundation’s had a long-lived incubator under that name. With their kind permission what was old is new again. We’re really excited about once again seeing Java innovation happening under the Jakarta banner.

jakartaee_logo

  • Define a process by which existing specifications can evolve, and new specifications can be included in the platform.

The first step in creating this process was to establish the Jakarta EE Working Group, which will be the governing body for this community moving forward. This was completed back in March, and the various committees are hard at work.

Discussions to create the new Jakarta EE Specification Process are underway, and early results are promising. This is going to be a very large job, but one which is essential to the future of this technology.

  • Recruit and enable developers and other community members, as well as vendors, to sponsor platform technologies, and bring the platform forward within the foundation. This would include potential incorporation of Eclipse MicroProfile technologies into the platform.

So far so good. Since the original announcement with Oracle, IBM and Red Hat back in September, here is the list of companies that have joined the initiative:

Strategic Members: Fujitsu, Payara, and Tomitribe

Participating Members: DocDuko, Genuitec, IncQueryLabs, Lightbend, London Java Community, Microsoft, Pivotal, RCPVision, SAP, UseOpen, Vaadin, and Webtide.

More importantly, we’ve seen a lot of developers from the Java EE community jump in and participate in the new projects as they’ve been set up. It has been great to welcome so many new people to the Eclipse community.

Eclipse MicroProfile has not joined the Jakarta EE initiative. But those conversations cannot even really start until the new specification process is available for that community to review.

  • Begin doing the above as soon as possible after completion of Java EE 8 to facilitate a rapid transition.

We’ve all been busy! It’s hard to say if the transition has been rapid enough, but everyone involved has been working hard and making progress. The process has not been and will not be perfect. With so many moving parts, people, and technologies, perfection is the enemy of good. But we’ve been very excited by the process we’re making. In particular, we have been excited by the passion and energy of the Java EE community as they have embraced the future with Jakarta EE.

Written by Mike Milinkovich

May 24, 2018 at 7:07 am

Posted in Foundation

A New Logo for the Eclipse Foundation

Since the beginning of the Eclipse Foundation in 2004 we have had two corporate logos, both of which happened to be the same logo as used by the Eclipse IDE. For a long time that was a good idea, as the Eclipse IDE was definitely our flagship project.

However, as the role of our Foundation has changed, that has made less and less sense. With exciting new technologies such as Jakarta EE, IoT, machine learning, quantum computing, etc., tying our identity to just one of our 350 projects makes it a lot more difficult to explain.  Our visual identity needs to line up with our role as a platform and environment for developers and organizations to collaborate.

To that end, we are going to soon be rolling out a new logo and website look-and-feel for the Eclipse Foundation. Our web team lead Christopher Guindon has blogged about what the new website look-and-feel will be like. It includes both a refresh in the look and feel, while still making it simple for developers to get to their favorite projects and downloads. 

But first, I get the exciting job of sharing our new logo with the world. We really like it, and hope you do too!

eclipsefoundationlogo_4

Written by Mike Milinkovich

April 10, 2018 at 8:00 am

Posted in Foundation

On Complexity and Good Intentions

We are now about six months into the process of migrating Java EE to the Eclipse Foundation, and I think we’re all learning a lot as we go. I wanted to take a moment and take stock of the scale of this project, its complexity, and where we are.

Java EE is a (roughly) twenty year old technology that is one of the world’s most successful software platforms. It powers the business critical applications that run our modern world. Millions of developers work with Java EE technologies every day. Billions of users use these systems every day. Throughout Java EE’s twenty year history it has been developed and marketed in a pretty particular way.

At the core of Java EE’s success has been an approach that enabled a multi-vendor ecosystem where enterprises had a choice of compatible implementations from a number of companies.

  • Java EE specifications were developed at the Java Community Process, using that JCP process where all intellectual property flowed to the Spec Lead, which was usually Sun (later Oracle). All participants in the specification process are signatories of the Java Specification Participation Agreement, which is a fairly complex legal document.
  • Progress and innovation in Java EE was largely governed by and driven within the constraints of this specification process.
  • Java EE reference implementations were, for the most part, developed by Oracle as part of the Glassfish (and related) project and made available under the CDDL and GPLv2+Classpath Exception licenses. Most of the developers were from Oracle, and the architectural vision and project management roles were performed by them. Contributors to the projects signed the Oracle Contributor Agreement that gave Oracle joint ownership of all contributions.
  • TCKs were developed entirely by Oracle and were highly confidential and tightly controlled. You had to sign an NDA just to get a copy of the TCK agreement if you were interested in getting access to the TCKs. The agreements were pretty dense and complex legal documents.
  • It was called Java EE. It had a logo that looked like a coffee cup. These trademarks were owned by Oracle and tightly controlled.
  • Generally speaking the big enterprises that used the technology were not involved in its evolution. For the most part, the contributors to the specs and implementations were from the Java EE platform vendors.

Together we are changing every single one of those items above. All at once. While retaining the core value of enabling compatible independent implementations in a multi-vendor ecosystem.

This is big and it is complicated.

I honestly believe that no institution other than the Eclipse Foundation could handle this task. We have the people, the skills, the history, and the knowledge of how the Java ecosystem works. The staff at the Eclipse Foundation are highly skilled and community minded professionals. Similarly, the team at Oracle, along with the folks from IBM, Payara, Red Hat, Tomitribe and the EE4J PMC are working hard to move this along. Collectively they are working their butts off to support this transition and to make Jakarta EE the platform and community of choice for the next twenty years.

Overall, I believe we’ve been pretty successful at managing the complexity, and working hard to communicate our progress and plans. We haven’t always been perfect, as case in point this past week where we had a bit of a kerfuffle on our Jakarta community mailing list. Without going into the details, I would say that the root cause of that was poor communication on my part. I didn’t do a good enough job in communicating the plans and dates for selecting the new logo. My bad.

Chris Anisczcyk, a good friend and open source community colleague of mine tweeted some months back that “Open source would be a lot more fun if everyone assumed good intentions.” With his wise words in mind, I want to say is this: what we are collectively undertaking here is a massive and complex task. Mistakes and miscommunications are going to happen. But let’s all assume good intentions, and build a community based on trust, honesty, and respect.

Written by Mike Milinkovich

March 23, 2018 at 10:18 am

Posted in Foundation

And the Name Is…

We are happy to announce that the new name for the technology formerly known as Java EE is….[insert drumroll]… Jakarta EE.

Almost 7,000 people voted in our community poll, and over 64% voted in favour of Jakarta EE. Thanks to everyone who voted, blogged, or tweeted! This has been quite the process, and we are all really happy with the community support throughout.

naming_poll_results

As we have been making progress on migrating Java EE to the Eclipse Foundation there have been a lot of moving pieces and parallel threads, especially around naming. Thankfully, we think we are getting to the end of this, and the names at least are starting to sort themselves out.  We have prepared this handy table to assist with the translation from the old names to the new names.

Eclipse Jakarta Working Group

Old Name New Name
Java EE Jakarta EE
Glassfish Eclipse Glassfish
Java Community Process (JCP) [*] Jakarta EE Working Group (Jakarta EE)
Oracle development management Eclipse Enterprise for Java (EE4J)
Project Management Committee (PMC)

Note that permission for products to formally use the Jakarta EE trademark will be dependent upon passing a as-yet-to-be-defined compatibility program run by EE.next. However, as of today, it is preferred that when you are generically referring to this open source software platform that you call it Jakarta EE rather than EE4J. EE4J, the Eclipse Top-level project,  is the only name we’ve had for a couple of months, but as we at least tried to make clear, that was never intended to be the brand name.

Update: Fixed a typo plus the formatting of the Glassfish row in the translation table.
Update 2: [*] To be clear, the Java Community Process will continue to exist and to support the Java SE and ME communities. However, it will not be the place where Jakarta EE specifications will be developed.
Update 3: Corrected the name of the working group from EE.next to Jakarta EE.

Written by Mike Milinkovich

February 26, 2018 at 2:00 pm

Posted in Foundation

Tagged with , ,

Introducing the EE.next Working Group

As part of our continuing adventures in migrating Java EE to the Eclipse Foundation I am pleased to announce that the draft of the EE.next Working Group charter  has now been posted for community review. Comments and feedback are welcomed on the ee4j-community@eclipse.org mail list. But please please pretty please make sure you read the FAQ (also copied below) before you do.

You can think of this EE.next group as the replacement for the Java Community Process for Java EE. It will be the body that the ecosystem can join and participate in at a corporate level. Individuals can also join if they are committers on EE4J projects. EE.next will also be the place where the new specification process will be created and managed, and where specs will be reviewed and approved.

Under the process for establishing Eclipse Foundation working groups, there will now be a community review period lasting a minimum of 30 days.

 

FAQ

What is the purpose of a working group?

An Eclipse Foundation working group is a special-purpose consortia of Eclipse Members interested in supporting a technology domain. They are intended to complement the activities of a collection of Eclipse Foundation open source projects. Open source projects are excellent for many things, but they typically do not do a great job with activities such as marketing, branding, specification and compliance processes, and the like.

What is the role of the PMC versus the working group or the working group Steering Committee?

Eclipse Foundation projects are self-governing meritocracies that set their own technical agendas and plans. The Project Management Committee for an Eclipse top-level project oversees the day-to-day activities of its projects through activities such as reviewing and approving plans, accepting new projects, approving releases, managing committer elections, and the like.

Working groups and their steering committees are intended to complement the work happening in the open source projects with activities that lead to greater adoption, market presence, and momentum. Specifically the role of the working group is to foster the creation and growth of the ecosystem that surrounds the projects.

Working groups do not direct the activities of the projects or their PMC. They are intended to be peer organizations that work in close collaboration with one another.

Who defines and manages technical direction?

The projects manage their technical direction. The PMC may elect to coordinate the activities of multiple projects to facilitate the release of software platforms, for example.

Because the creation of roadmaps and long term release plans can require market analysis, requirements gathering, and resource commitments from member companies, the working group may sponsor complementary activities to generate these plans. However, ultimately it is up to the projects to agree to implement these plans or roadmaps. The best way for a working group to influence the direction of the open source projects is to ensure that they have adequate resources. This can take the form of developer contributions, or under the Member Funded Initiatives programs, working groups can pool funds to contract developers to implement the features they desire.

Why are there so many levels of membership?

Because the Java EE ecosystem is a big place, and we want to ensure that there are roles for all of the players in it. We see the roles of the various member classes to roughly align as follows:

  • Strategic members are the vendors that deliver Java EE implementations. As such they are typically putting in the largest number of contributors, and are leading many of the projects.
  • Influencer members are the large enterprises that rely upon Java EE today for their mission critical application infrastructure, and who are looking to EE.next to deliver the next generation of cloud native Java. They have made strategic investments in this technology, have a massive skills investment in their developers, and want to protect these investments as well as influence the future of this technology.
  • Participant members are the companies that offer complementary products and services within the Java EE ecosystem. Examples include ISVs which build products on Java EE, or system integrators that use these technologies in delivering solutions to their customers.
  • Committer members are comprised of the committers working on the various EE4J projects who are also members of the Eclipse Foundation. While the Eclipse bylaws define the criteria for committers to be considered members, in essence any committer members are either a) a committer who is an employee of an EE.next member company or b) any other committer who has explicitly chosen to join as a member. Giving Committer members a role in the working group governance process mimics the governance structure of the Eclipse Foundation itself, where giving committers an explicit voice has been invaluable.

What makes this different from the Java Community Process (JCP)?

The EE.next working group will be the successor organization to the JCP for the family of technologies formerly known as Java EE. It has several features that make it a worthy successor to the JCP:

  1. It is vendor neutral. The JCP was owned and operated first by Sun and later by Oracle. EE.next is designed to be inclusive and diverse, with no organization having any special roles or rights.
  2. It has open intellectual property flows. At the JCP, all IP flowed to the Spec Lead, which was typically Oracle. We are still working out the exact details, but the IP rights with EE.next and EE4J will certainly not be controlled by any for-profit entity.
  3. It is more agile. This is an opportunity to define a 21st century workflow for creating rapidly evolving Java-based technologies. We will be merging the best practices from open source with what we have learned from over 15 years of JCP experience.

Is the WG steering committee roughly equivalent to the JCP Executive Committee?

No, not really. The JCP EC always had two mixed roles: as a technical body overseeing the specification process, and as an ecosystem governance body promoting Java ME, SE, and EE. In EE.next the Steering Committee will be the overall ecosystem governance body. The EE.next Specification Committee will focus solely on the development and smooth operation of the technical specification process.

Does a project have to be approved as a spec before it can start?

That is actually a decision which will be made by the EE4J PMC, not the working group. However, it is a goal of the people and organizations working on creating this working group that the Java EE community move to more of a code-first culture. We anticipate and hope that the EE4J PMC will embrace the incubation of technologies under its banner. Once a technology has been successfully implemented and adopted by at least some in the industry, it can then propose that a specification be created for it.

In addition to the Steering Committee, what other committees exist?

There are four committees comprising the EE.next governance structure – the Steering Committee, the Specification Committee, the Marketing and Brand Committee, and the Enterprise Requirements Committee. A summary of the make-up of each of the committees is in the table below.

Strategic Member Influencer Member Participant Member Committer Member
Member of the Steering Committee Appointed Elected Elected Elected
Member of the Specification Committee Appointed Elected Elected Elected
Member of the Marketing Committee Appointed Elected Elected Elected
Member of the Enterprise Requirements Committee Appointed Appointed N/A N/A

Written by Mike Milinkovich

February 5, 2018 at 2:43 pm

Posted in Foundation

EE4J: Current Status and What’s Next

There is a lot going on as Java EE continues its migration to the Eclipse Foundation. Since there are so many parallel threads, I thought it would be a good idea to recap where we are, and what is coming up in the next few weeks.

First off, we are continuing to work on arriving at a new brand name. Last week the PMC provided the Eclipse Foundation with a potential list of names, and we are running trademark reviews to see if we believe that they can be properly secured. Obviously, we need to have a high degree of confidence that we can freely use the name around the world if we are going to use it to replace some as well known as Java EE. Once we have a short list of potentials we will be starting a community vote to help arrive at a final choice.

Secondly, the code is moving from the existing Oracle-led Java EE organization on GitHub into EE4J. The first nine projects which were proposed have all been created and provisioned, and the code is being moved into them as we speak. The next step on this front will be to propose the next round of projects to move next. As I understand it, the Oracle team will be proposing the JSON-B API and JavaMail projects next. Soon after will come JAX-B, JAX-WS, JSTL, UEL, JAF, Security, JTA, Enterprise Management, Concurrency, and Common Annotations. Everyone involved strongly believes that a key factor in the success of this entire migration is the rapid creation of a diverse and engaged open source community around this code, so we are moving as rapidly as possible to get these projects up and running.

We want to demonstrate to the world that these projects are capable of shipping. Therefore the short-term objective is to have the EE4J project ship a Java EE 8-compliant release as quickly as possible: i.e. a Java EE 8 certified release of Eclipse Glassfish and related projects. There are a couple of positive reasons for doing this:

  1. It demonstrates that the EE4J projects are fully functional as open source projects, and that they and the PMC can run through the full process of a release under the auspices of the Eclipse Foundation and the Eclipse Development Process.
  2. It gets downloadable code that users and adopters can access and run from EE4J as quickly as possible. Creating an ecosystem of developers and companies using this code is important, and the sooner we start the better.

A comment on the API projects that are moving over: several have asked on the mailing lists if the fact that the source has moved means that we can start changing the APIs directly in the EE4J projects. The short answer is “please, not quite yet”. There are several reasons for that:

  1. We want to focus in the short term on shipping an EE 8 compliant release. So the fewer moving parts while we’re doing that, the better.
  2. There is going to be a new spec process that is going to be managing the evolution of these APIs in the future, and it hasn’t been set up yet.
  3. As has been discussed in several venues, this new spec process is going to be bootstrapped with some rules around the continued use of the javax namespace. We’re still working on what those rules are.

In the meantime if you really want to start prototyping some new APIs you are always free to fork the repos on GitHub.

Finally, we are working on establishing an Eclipse Foundation working group to provide a member-driven governance model for the EE4J community. Working groups are consortia which complement the Eclipse open source projects. Community-driven open source projects are great for a lot of things, but don’t do well with business and ecosystem topics such as marketing, developer outreach, branding, specifications, compliance programs, and the like. The first step in creating a working group is to write its core governance charter. We hope to have a draft of that available for review by the end of the month as well. My next blog post will provide some additional information and background on that topic.

Written by Mike Milinkovich

January 23, 2018 at 12:48 pm

Posted in Foundation