Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

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

Close to the Edge

Today we are launching our new Edge Native Working Group to help drive the industry platform for edge computing. The new group has hit the ground running with everything needed to accelerate adoption of enterprise applications at the edge: a mature code base that’s already widely deployed in production environments, strong endorsements and participation from industry heavyweights, strong collaborations with other industry organizations such as the CNCF, and a deep understanding of the key challenges ahead.

But before turning to the details of the announcement, let’s talk a little about how edge computing differs from related technologies such as cloud and IoT.

To me, edge computing differs from IoT in that IoT is historically a bottom up approach. The people who talk about IoT are likely coming from an embedded systems or industrial automation background, and are looking for new, open stacks to connect their OT systems to modern cloud infrastructure.

Edge computing is more of a top down approach where people are looking for how they can take the new generation of cloud infrastructure and use it to solve problems at the edge of the network. Edge computing does not necessarily differ from cloud computing in terms of compute power (multiprocessor 64-bit x86 or ARM with gigabytes of RAM) or software stack (containers, Kubernetes, and microservices). The single most important differentiator between cloud compute and edge compute is simply “do you know (or care) where the resources are located”? If the answer to that is yes, then you are in the realm of edge computing. In addition, the requirement to deal with the transparent orchestration of microservices from cloud to edge is key.

Edge Accelerates Applications

Artificial intelligence (AI) and autonomous vehicle applications are two great examples of why there is massive interest in edge computing. Pushing applications out to the edge of the network is the only way to efficiently transfer and analyze the massive amounts of data AI applications rely on. And, it’s the only way to achieve the sub-one-millisecond latency autonomous vehicle applications require.

With the Edge Native Working Group, the global community can collaborate to evolve the commercial-grade, production-ready code base we already have in Eclipse ​ioFog​, Eclipse ​fog05​, and other projects to address technical issues that are specific to the edge:

  • Running applications on a wider variety of hardware than you would find in a data center
  • Dealing with the fact that at the edge, the physical location of your resources matters
  • Maintaining communications when you’re forced to rely on low-bandwidth, intermittent network connections while also scaling to scenarios that rely on 5G and other high bandwidth technologies
  • Ensuring the security of edge devices that are often installed in easily accessible locations (read the Edge Security Challenges whitepaper published by the Kubernetes IoT Edge working group)

Resolving these challenges will allow the Edge Native Working Group to bring EdgeOps — DevOps for the edge — to the world so developers can write software and can deploy, run, and manage it where it needs to, whether that’s on an MRI machine in a hospital, a motion-activated camera in a farmer’s field, or a fleet of vehicles.

The Market for Edge Computing Is Here and It’s Huge

Interest in resolving edge-specific issues is extremely high. Our founding member list is an impressive group of industry leaders, such as ADLINK, Bosch, Edgeworx, Eurotech, Kynetics, Huawei, Intel, and Siemens. We’re also actively engaged in discussions with other influential global players and expect to share news about additional working group members in the near future.

The stature and breadth of companies joining the Edge Native Working Group confirms the need for an open source industry group with edge code that’s ready to be used in serious deployments. According to a 2019 Allied Market Research report, edge computing is forecast to generate a market worth $16.5 billion within the next five years.

The business potential at the edge is as varied as the companies joining the working group. For a chip developer, the Edge Native Working Group offers access to an industry ecosystem that can showcase the speed of their products in AI and data analytics applications at the edge. A global telecom player can ensure its products are aligned with edge computing standards to enable 5G applications at the edge.

And on it goes, with the potential for companies in any industry to leverage the open platforms the Edge Native Working Group is developing to build customized edge applications for their specific markets and opportunities.

Get Closer to the Edge at the Eclipse Foundation

Critical new initiatives, such as the creation of the Edge Native Working Group, can only happen when Eclipse Foundation community members come together to drive them forward. I want to sincerely thank everyone involved in getting the Edge Native Working Group off the ground for their dedication and meaningful contributions. The tremendous interest and success we’ve experienced so far is a true testament to the value of the time and effort this very devoted team has committed to the project.

With the incredibly broad and bright future the Eclipse Edge Native Working Group offers, I encourage everyone to visit http://edgenative.eclipse.org/, review the ​charter​ and the ​Edge Native Working Group Participation Agreement (WPGA), or email us at membership@eclipse.org for more information. You can also join the working group’s mailing list to receive progress updates.

If you’ll be attending Edge Computing World on Dec 9-12 in San Jose, California, be sure to attend the Eclipse Edge Tools developer workshop on Tuesday, December 10 at 11:30 AM local time. Also, drop by and see us at our table in the main foyer on the second floor of the Computer History Museum, where we’ll be showcasing the ioFog, ​fog05​, and the Edge Native Working Group.

 

Written by Mike Milinkovich

December 10, 2019 at 7:00 am

Posted in Foundation

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