Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

Real-World IoT Adoption

The results of our first IoT Commercial Adoption survey tell a clear story about what organizations are doing with IoT right now and their plans for production deployments. The goal of the survey was to go beyond the IoT Developer Survey we’ve conducted for the last six years to gain insight into the industry landscape from the point of view of a broader spectrum of IoT ecosystem stakeholders.

Here are some of the key findings from the survey:

  • IoT may well live up to the hype, if somewhat slower than expected. Just under 40 percent of survey respondents are deploying IoT solutions today. Another 22 percent plan to start deploying IoT within the next two years.
  • IoT investment is on the rise, with 40 percent of organizations planning to increase their IoT spending in the next fiscal year.
  • Open source pervades IoT as a key enabler with 60 percent of companies factoring open source into their IoT deployment plans.
  • Hybrid clouds lead the way for IoT deployments. Overall, AWS, Azure, and GCP are the leading cloud platforms for IoT implementations.

The Commercial Perspective Is Crucial

The survey asked respondents to identify the requirements, priorities, and challenges they’re facing as they deploy and start using commercial IoT solutions, including those based on open source technologies. The survey ran for two months last fall and received responses from more than 360 individuals from a wide range of industries and organizations. You can read the full survey results here, and I would encourage IoT ecosystem players to do that.

IoT Ecosystem Players Must Focus on Real-World Requirements

As our survey results revealed, each player in the IoT ecosystem has an important role in driving IoT adoption. Here are some key takeaways broken down by stakeholder group.

  • Software vendors should incorporate open source technologies into their solutions to give customers the flexibility and control they need.
  • IoT platform vendors should build offerings that support hybrid cloud environments to become more responsive to customer requirements. At least part of the reason multi-cloud adoption is still in its early stages is because — not surprisingly — the leading cloud providers don’t offer their IoT platform services on other cloud platforms.
  • IoT solution providers should be prepared for extensive and intensive proofs of concept and pilot projects before they get to the stage of full production rollouts. With companies reluctant to invest heavily in IoT before they’re confident in the return on investment, these practical and tangible demonstrations will be key to encouraging broader adoption.
  • Manufacturing organizations should implement IoT solutions that tie automation, asset management, and logistics together. The most innovative organizations will also rely on IoT technologies to improve their value proposition to customers, for example, by including preventive maintenance features on manufacturing equipment.

Get Involved in Eclipse IoT

It will take a diverse community co-developing a uniform set of building blocks based on open source and open standard to drive broad IoT adoption. If you’re interested in participating in the industry-scale collaboration happening at the Eclipse IoT Working Group or contributing to Eclipse IoT projects, please visit https://iot.eclipse.org/.

As an added benefit of membership, Eclipse IoT Working Group members receive exclusive access to detailed industry research findings, including those from the annual IoT Developer Survey, which are leveraged by the entire industry.

The 2020 IoT Developer Survey is coming soon. If you’d like to contribute questions or provide feedback, join the working group mailing list here.

Written by Mike Milinkovich

March 10, 2020 at 12:57 pm

Sparkplug: Standardizing Industrial IoT Communications

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

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