Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

Archive for the ‘Open Source’ Category

Sparkplug: Standardizing Industrial IoT Communications

leave a comment »

With the launch this week of the Sparkplug Working Group, we’re bringing together the industry leaders and technologies needed to drive development and broad adoption of the Eclipse Sparkplug specification for open, interoperable, Industrial IoT (IIoT) solutions that use the MQTT protocol.

MQTT is an open and lightweight publish-subscribe messaging protocol that was first developed in the late 1990s for real-time message transport in Supervisory Control and Data Acquisition (SCADA) systems. Because it’s designed for low-bandwidth, low-power environments, it’s ideal for IIoT and industrial automation applications that rely on data from massive numbers of sensors.

Sparkplug Augments MQTT With IIoT Interoperability Essentials

Today, MQTT is the dominant messaging protocol for IIoT applications, but it doesn’t define the data format and it doesn’t address issues around device compatibility and interoperability — capabilities that are essential in IoT environments where all device and software services must share a common data format and support the same life cycle stages of device information.

The Sparkplug specification will resolve these issues. It will define an MQTT topic namespace, payload, and session state management approach that can be applied generically. The goal is to provide standardization for most MQTT devices out of the box so vendors, manufacturers, and industrial end users can develop an ecosystem of solutions and devices that can easily interoperate.

Broad Support Across Industries

With the Sparkplug Working Group’s focus on specifications and implementations that rationalize industrial data and improve the interoperability and scalability of IIoT solutions, companies in industries ranging from oil and gas to energy, manufacturing, and smart cities will have an overall framework to support their evolution to Industry 4.0.

The breadth and stature of the Sparkplug Working Group’s founding members confirm the huge need for industrial system interoperability and the value of the Sparkplug initiative across industries. Founding members include global leaders, such as Chevron, Canary Labs, Cirrus Link Solutions, HiveMQ, Inductive Automation, and ORing.

These companies, and others, are embracing Sparkplug to take IIoT applications to the next level with MQTT implementations that provide valuable, real-time information in a highly reliable, scalable, and secure way.

Get Involved With Sparkplug

I’m very excited about the huge potential and opportunities that will open up for everyone involved in IIoT and industrial automation as the Sparkplug Working Group pushes forward to standardize MQTT device communications. This is truly transformative technology, and I want to sincerely thank all of the corporations and individuals who have brought us to this point.

To get involved with the Eclipse Sparkplug Working Group and contribute to the project, please visit https://sparkplug.eclipse.org.

Also, the Eclipse Foundation and our member companies will be showcasing the Sparkplug Working Group at the ARC Advisory Group’s 24th Annual Industry Forum, February 3-6 in Orlando. If you’re at the Forum, be sure to drop by Inductive Automation’s booth (booth #25) to learn more.

Written by Mike Milinkovich

February 6, 2020 at 8:08 am

Posted in Foundation, Open Source

Cloud Native for Java Day @ KubeCon EU

leave a comment »

Cloud Native for Java (CN4J) Day at KubeCon + CloudNativeCon Europe will be the first time the best and brightest minds from the Java ecosystem and the Kubernetes ecosystem come together at one event to collaborate and share their expertise.

The all-day event on March 30 includes expert talks, demos, and thought-provoking sessions focused on building cloud native enterprise applications using Jakarta EE-based microservices on Kubernetes. CN4J Day is a proud moment for all of us at the Eclipse Foundation as it confirms the Jakarta EE and MicroProfile communities are at the forefront of fulfilling the promise of cloud native Java. We’re excited to be working with our friends at the CNCF to offer this event co-located with KubeCon Europe.

A Unique Opportunity to Engage With Global Experts

The timing of CN4J Day could not be better. With momentum toward the Jakarta EE 9 release building, this event gives all of us an important and truly unique opportunity to:

  •     Learn more about the future of cloud native Java development from industry and community leaders
  •     Gain deeper insight into key aspects of Jakarta EE, MicroProfile, and Kubernetes technologies
  •     Meet and share ideas with global Java and Kubernetes ecosystem innovators

The global Java ecosystem has embraced CN4J day and several of its leading minds will be on-hand to share their insights. Along with keynote addresses from my colleague Tanja Obradovic and IBM Java CTO, Tim Ellison, CN4J Day features informative technical talks from Java experts and Eclipse Foundation community members, such as:

  •     Adam Bien, an internationally recognized Java architect, developer, workshop leader, and author
  •     Sebastian Daschner, lead java developer advocate at IBM
  •     Clement Escoffier, principal software engineer at Red Hat
  •     Ken Finnegan, senior principal engineer at Red Hat
  •     Emily Jiang, liberty architect for MicroProfile and CDI at IBM
  •     Dmitry Kornilov, Jakarta EE and Helidon Team Leader at Oracle
  •     Tomas Langer, Helidon Architect & Developer at Oracle

Major Industry and Ecosystem Endorsement

Leading industry players in the Java ecosystem are also showing their support for CN4J Day through sponsorship. Our sponsors include:

  •     Cloud Native Computing Foundation (CNCF)
  •     IBM
  •     Oracle
  •     Red Hat

The event is being coordinated by an independent program committee composed of Arun Gupta, principal technologist at Amazon Web Services, Reza Rahman, principal program manager for Java on Azure at Microsoft, and Tanja Obradovic, program manager for Jakarta EE at the Eclipse Foundation.

Register Today

To register today, simply add the event to your KubeCon + CloudNativeCon Europe registration. Thanks to the generous support of our sponsors, a limited amount of discounted CN4J Day add-on registrations will be made available to Jakarta EE and MicroProfile community members on a first-come, first-served basis.

For more details about CN4J Day and a link to the registration page, click here. For additional questions regarding this event, please reach out to events-info@eclipse.org.

As additional speakers and sponsors come onboard, we’ll keep you posted, so watch for updates in our blogs and newsletters.

Written by Mike Milinkovich

January 28, 2020 at 7:00 am

Moving Forward With Jakarta EE 9

On behalf of the Jakarta EE Working Group, I am excited to announce the unanimous approval of the plan for Jakarta EE 9, with an anticipated mid-2020 release. Please note that the project team believes this timeline is aggressive, so think of this as a plan of intent with early estimate dates. The milestone dates will be reviewed and possibly adjusted at each release review.

If you have any interest at all in the past, present, or future of Java, I highly recommend that you read that plan document, as Jakarta EE 9 represents a major inflection point in the platform.

The key elements of  this Jakarta EE 9 release plan are to:

  • move all specification APIs to the jakarta namespace (sometimes referred to as the “big bang”);
  • remove unwanted or deprecated specifications;
  • minor enhancements to a small number of specifications;
  • add no new specifications, apart from specifications pruned from Java SE 8 where appropriate; and
  • Java SE 11 support.

What is not in the plan is the addition of any significant new functionality. That is because the goals of this Jakarta EE 9 release plan are to:

  • lower the barrier of entry to new vendors and implementations to achieve compatibility;
  • make the release available rapidly as a platform for future innovation; and
  • provide a platform that developers can use as a stable target for testing migration to the new namespace.

Moving a platform and ecosystem the size and scale of Jakarta EE takes time and careful planning. After a great deal of discussion the community consensus was that using EE 9 to provide a clear transition to the jakarta namespace, and to pare down the platform would be the best path to future success. While work on the EE 9 platform release is proceeding, individual component specification teams are encouraged to innovate in their individual specifications, which will hopefully lead to a rapid iteration towards the Jakarta EE 10 release.

Defining this release plan has been an enormous community effort. A lot of time and energy went into its development. It has been exciting to watch the … ummm passionate…. discussions evolve towards a pretty broad consensus on this approach. I would like to particularly recognize the contributions of Steve Millidge, Kevin Sutter, Bill Shannon, David Blevins, and Scott Stark for their tireless and occasionally thankless work in guiding this process.

The Jakarta EE Working Group has been busy working on creating a Program Plan, Marketing Plan and Budget for 2020. The team has also been very busy with creating a plan for the Jakarta EE 9 release. The Jakarta EE Platform project team, as requested, has delivered a proposal plan to the Steering Committee. With their endorsement, it will be voted on by the Specification Committee at their first meeting in January 2020.

Retrospective

The Jakarta EE 9 release is going to be an important step in the evolution of the platform, but it is important to recognize the many accomplishments that happened in 2019 that made this plan possible.

First, the Eclipse Foundation and Oracle successfully completed some very complex negotiations about how Java EE would be evolved under the community-led Jakarta EE process. Although the Jakarta EE community cannot evolve the specifications under the javax namespace, we were still able to fully transition the Java EE specifications to the Eclipse Foundation. That transition led to the second major accomplishment in 2019: the first release of Jakarta EE. Those two milestones were, in my view, absolutely key accomplishments. They were enabled by a number of other large efforts, such as creating the Eclipse Foundation Specification Process, significant revisions to our IP Policy, and establishing the Jakarta EE compatibility program. But ultimately, the most satisfying result of all of this effort is the fact that we have seven fully compatible Jakarta EE 8 products, with more on the way.

The Jakarta EE community was also incredibly active in 2019. Here are just a few of the highlights:

2019 was a very busy year, and it laid the foundation for a very successful 2020. I, and the entire Jakarta EE community, look forward to the exciting progress and innovation coming in 2020.

Written by Mike Milinkovich

January 16, 2020 at 12:06 pm

Re-Defining Cloud Development Tools

The Eclipse community is seriously on a roll these days. Hot on the heels of the Eclipse Che 7 release, we just announced the Eclipse Cloud Development (ECD) Tools Working Group, a vendor-neutral, open source collaboration that will focus on the evolution of development tools for, and in, the cloud.

I haven’t seen an initiative with the potential impact on the development tools industry since the founding of the Eclipse Foundation back in 2004, when we hosted around 12 projects related to the Eclipse IDE.

When the first Eclipse IDE was launched, it fulfilled the need for a vendor-neutral development environment that would help developers adapt to rapidly changing middleware technologies and business priorities including enterprise Java and Web services. Those were the megatrends at the time. And the impact of the Eclipse IDE was massive, as it drove a decade of enormous adoption and industry consolidation around developer tools.

While the Eclipse IDE is still extremely relevant, better than ever, and is actively used by more than four million developers, today the megatrend is cloud development. And, the world needs open source technologies and tools to drive the development of cloud native applications. The purpose of the ECD Tools group is to deliver modern, extensible, web-based developer tool platforms that can be used by everyone to enable their own cloud enablement strategies.

Huge Demand for Open Source Cloud Development Technologies

We know from the responses to our developer surveys and the enthusiastic responses to our recent Jakarta EE 8 release that there’s huge demand for open source cloud development technologies. More than 80 percent of the Java developers we surveyed earlier this year told us they either are already or plan to create cloud native applications within the next 12-18 months.

However, many developers are well beyond the planning stage. The growth and explosion of the Kubernetes container orchestration platform confirms the urgency to deliver open source cloud development technologies is very real today.

Che 7 is the world’s first Kubernetes-native IDE that’s built from the ground up for cloud native application development. It simplifies and accelerates cloud development by allowing developers who are not Kubernetes experts to immediately contribute to cloud native application development efforts. In turn, Che 7 relies upon Eclipse Theia, which provides a highly modular and extensible IDE platform built on modern web technologies that runs on both your desktop or in your browser.

Accelerating Open Source, Cloud Native Development

The ECD Tools Working Group takes our open source cloud development initiatives to the next level.

The Working Group will drive the evolution and widespread adoption of emerging standards for cloud-based developer tools, including language support, extensions, and developer workspace definition. These efforts will accelerate adoption of a Cloud IDE and container-based workspace management.

With such a broad scope, it will come as no surprise to learn that the ECD Tools Working Group encompasses a wide range of open source cloud development projects, including Eclipse Che, Eclipse Theia, Eclipse CodeWind, Eclipse Dirigible, Eclipse Sprotty, and others.

Big-Name Support and Involvement

We could not create a working group of this magnitude and with this potential without the incredible level of support we’ve received from the founding members of this group.

When companies such as Broadcom, EclipseSource, Ericsson, IBM, Intel, Red Hat, SAP, Software AG, Typefox, and others support an initiative so strongly from its earliest days, you get a sense of just how important it is considered to be. Every one of our founders is a respected leader in their space, and we have a mix of large corporations and smaller companies, which is always great to see.

Unstoppable Momentum

I want to thank everyone who has helped us create and launch the ECD Tools Working Group. With the incredible groundswell of interest, engagement, and participation we’re seeing from both world-leading corporations and passionate developers, I truly believe we are standing on the doorstep of a very exciting open source future for cloud development tools. And, I have no doubt this community will continue to grow and thrive.

To learn more about getting involved with the ECD Tools Working Group, view the Charter and ECD Tools Working Group Participation Agreement (WPGA), or email us at membership@eclipse.org. You can also join the ECD Tools mailing list and follow @ECDTools on Twitter.

 

Written by Mike Milinkovich

October 8, 2019 at 6:30 am

Posted in Foundation, Open Source

Eclipse Che 7 Enables Faster, Safer Development on Kubernetes

A major version release within the Eclipse Foundation community always provides us a reason to celebrate, congratulate, and thank all those who participated and contributed to the process. The delivery today of Eclipse Che 7 is no exception. But Che 7’s arrival is more than great news for the Eclipse community, it’s also an industry game changer because it drastically reduces the learning and adoption curves of Kubernetes for enterprise application developers.

Che 7 is the result of more than six years of collaboration and community contributions, including more than 20 vendors. It’s the world’s first Kubernetes-native IDE that has been built from the ground up specifically to enable developers to build cloud native applications. Fundamentally, Che 7 makes the developer and production environments the same on a scalable, collaborative, and secure platform specifically designed for building containerized applications. That platform addresses the major challenges developers face when working with Kubernetes.

While Kubernetes does a fantastic job of operating applications at scale, it’s a complex system that most developers do not yet fully understand. With Che 7, the workspace configuration complexities and challenges developers face with Kubernetes have been eliminated. The platform can be deployed on a public Kubernetes cluster or an on-premises data center. Once deployed, it provides centrally hosted private developer workspaces that make projects easy to share and easy to manage, but with enterprise-grade security.

Che 7 takes care of the “Kubernetization” of the development environment and the applications that a developer is building. It comes with a pre-packaged web-based IDE, based on an extended version of Eclipse Theia to provide an in-browser Visual Studio Code experience. The fully integrated environment containerizes everything a developer needs to develop, build, run, test, and debug enterprise cloud native applications. This includes all of the tools and dependencies. This a big deal considering many enterprises cite a lack of integration of development tools and processes as a primary challenge of container adoption.

The introduction of Che 7 represents another milestone in enterprise-grade, cloud native tooling innovation from the Eclipse Foundation and our community. It continues the Eclipse Foundation track record of delivering innovative tools to the development community, most notably through the Eclipse desktop IDE. Che is already integral to cloud native solutions from our vendor community, including Google, IBM, and Broadcom. It also comprises the core of Red Hat CodeReady Workspaces, a new development environment for Red Hat OpenShift.

As we move forward, our community will continue to deliver more innovation through the Eclipse Cloud Development (ECD) Tools Working Group. In addition to Che, the ECD WG encompasses a broad portfolio of open source cloud development projects including Theia, Eclipse CodeWind, Eclipse Dirigible, Eclipse Sprotty, Eclipse Orion, and many more. The ECD WG will drive the evolution and adoption of de facto standards for cloud development tools, including language support, extensions, and developer workspace definitions.

Of course, Che 7 and the ECD WG are made possible by our development community. So, I thank all of those who have participated to date and encourage everyone to take part in the innovation process. To that end, we are actively recruiting members to the Eclipse Cloud Development Working group and we encourage and welcome new members.

Get started with Che 7 on any Kubernetes cluster at https://www.eclipse.org/che/ or learn more about getting started with Che at https://www.eclipse.org/che/getting-started/. To get involved with the Che community and contribute to the project, visit: https://github.com/eclipse/che/blob/master/CONTRIBUTING.md

 

Written by Mike Milinkovich

September 17, 2019 at 10:00 am

Posted in Foundation, Open Source

Welcome to the Future of Cloud Native Java

Today, with the release of Jakarta EE 8, we’ve entered a new era in Java innovation.

Under an open, vendor-neutral process, a diverse community of the world’s leading Java organizations, hundreds of dedicated developers, and Eclipse Foundation staff have delivered the Jakarta EE 8 Full Platform, Web Profiles, and related TCKs, as well as Eclipse GlassFish 5.1 certified as a Jakarta EE 8 compatible implementation.

To say this a big deal is an understatement. With 18 different member organizations, over 160 new committers, 43 projects, and a codebase of over 61 million lines of code in 129 Git repositories, this was truly a massive undertaking — even by the Eclipse community’s standards. There are far too many people to thank individually here, so I’ll say many thanks to everyone in the Jakarta EE community who played a role in achieving this industry milestone.

Here are some of the reasons I’m so excited about this release.

For more than two decades, Java EE has been the platform of choice across industries for developing and running enterprise applications. According to IDC, 90 percent of Fortune 500 companies rely on Java for mission-critical workloads. Jakarta EE 8 gives software vendors, more than 10 million Java developers, and thousands of enterprises the foundation they need to migrate Java EE applications and workloads to a standards-based, vendor-neutral, open source enterprise Java stack.

As a result of the tireless efforts of the Jakarta EE Working Group’s Specification Committee, specification development follows the Jakarta EE Specification Process and Eclipse Development Process, which are open, community-driven successors to the Java Community Process (JCP) for Java EE. This makes for a fully open, collaborative approach to generating specifications, with every decision made by the community — collectively. Combined with open source TCKs and an open process of self-certification, Jakarta EE significantly lowers the barriers to entry and participation for independent implementations.

The Jakarta EE 8 specifications are fully compatible with Java EE 8 specifications and include the same APIs and Javadoc using the same programming model developers have been using for years. The Jakarta EE 8 TCKs are based on and fully compatible with Java EE 8 TCKs. That means enterprise customers will be able to migrate to Jakarta EE 8 without any changes to Java EE 8 applications.

In addition to GlassFish 5.1 (which you can download here), IBM’s Open Liberty server runtime has also been certified as a Jakarta EE 8 compatible implementation. All of the vendors in the Jakarta EE Working Group plan to certify that their Java EE 8 implementations are compatible with Jakarta EE 8.

 All of this represents an unprecedented opportunity for Java stakeholders to participate in advancing Jakarta EE to meet the modern enterprise’s need for cloud-based applications that resolve key business challenges. The community now has an open source baseline that enables the migration of proven Java technologies to a world of containers, microservices, Kubernetes, service mesh, and other cloud native technologies that have been adopted by enterprises over the last few years.

As part of the call to action, we’re actively seeking new members for the Jakarta EE Working Group. I encourage everyone to explore the benefits and advantages of membership. If Java is important to your business, and you want to ensure the innovation, growth, and sustainability of Jakarta EE within a well-governed, vendor-neutral ecosystem that benefits everyone, now is the time to get involved.

Also, if you’re interested in learning more about our community’s perspective on what cloud native Java is, why it matters so much to many enterprises, and where Jakarta EE technologies are headed, download our new free eBook, Fulfilling the Vision for Open Source, Cloud Native Java. Thank you to Adam Bien, Sebastian Daschner, Josh Juneau, Mark Little, and Reza Rahman for contributing their insights and expertise to the eBook.

Finally, if you’ll be at Oracle Code One at the Moscone Center in San Francisco next week, be sure to stop by booth #3228, where the Eclipse community will be showcasing Jakarta EE 8, GlassFish 5.1, Eclipse MicroProfile, Eclipse Che, and more of our portfolio of cloud native Java open source projects.

 

Written by Mike Milinkovich

September 10, 2019 at 7:00 am

Eclipse ioFog: Evolving Toward Native Kubernetes Orchestration at the Edge

With the proliferation of AI, autonomous vehicles, 5G, IoT, and other industrial use cases that require lightning-fast data processing, edge computing has emerged over the past few years as a way to address the limitations of existing cloud architectures to process information and deliver services at the “IoT edge”. Instead of backhauling data to the centralized cloud, edge computing brings computational power closer to data sources to support near real-time insights and local actions while reducing network bandwidth and storage requirements.

According to Gartner, 75% of enterprise-generated data will be created and processed outside a traditional centralized data center or cloud by 2025. While the problems at the IoT edge — connectivity, manageability, scalability, reliability, security — are being solved as point solutions by enterprises and ecosystem players, there is a need for a foundational industry-wide standard for managing distributed IoT workloads. Time and again, open source has been proven to be the best way to deliver complex platform software with industrial scale collaboration.

Enter Kubernetes, the de facto standard for orchestrating containers and the applications running inside them. Kubernetes has massive potential for handling IoT workloads on the edge by providing a common control plane across hybrid cloud and edge environments to simplify management and operations. Within the Kubernetes IoT Edge Working Group, members of the Kubernetes and Eclipse communities are collaborating with leading technology innovators to extend Kubernetes to support dynamically, securely, and remotely managing edge nodes.

A great example of this collaboration is Eclipse ioFog, a universal Edge Compute Platform which offers a standardized way to develop and remotely deploy secure microservices to edge computing devices. ioFog can be installed on any hardware running Linux and provides a universal runtime for microservices to dynamically run on the edge. Companies in different vertical markets such as retail, automotive, oil and gas, telco, and healthcare are using ioFog to turn any compute device into an edge software platform.

The Eclipse Foundation is excited to support today’s announcement of the initial availability of ioFog features that make any Kubernetes distribution edge-aware. With this latest release, developers are able to extend Kubernetes to easily deploy, secure, and manage edge computing networks supporting applications such as advanced AI and machine learning algorithms.

Farah Papaioannou, co-founder and president of Edgeworx, explains the significance of the release this way:

“ioFog is a proven platform at the edge. With this release, we build on native Kubernetes, seamlessly extending it to the edge…We do this based on things that actually matter at the edge, such as latency, location or resources. We are delivering today a full cloud-to-edge solution, that’s 100-percent open source and works with any Kubernetes flavors and distros.”

These native Kubernetes enhancements are in the process of being contributed to the Eclipse ioFog open source project. We are proud to support the collective efforts of the Eclipse community and the Kubernetes ecosystem to help developers deploy, manage, and orchestrate applications and microservices from cloud to edge in a simple and secure manner.

For more information about ioFog, get started by using this link to install and set up your production ioFog environment. If you have questions or want to connect with other people involved in this platform, join the ioFog community and the mailing list.

Written by Mike Milinkovich

June 23, 2019 at 4:46 pm

Posted in Foundation, Open Source