Are microservices the next big thing for PLM? With social media, cloud and mobile technologies setting new benchmarks for speed, agility, and user-friendliness, today’s users expect similar performance and flexibility from Product Lifecycle Management (PLM) platforms.
While the business case for embracing more user-friendly and flexible technology is widely documented, software vendors have historically shied away from it, given the big changes to their core architecture and business models it demands. Opting for radical change in well-established and tested platforms, starting from scratch, is a risky path.
Risk, however, is an inescapable part of every business strategy, and the rise of cloud computing and open APIs has radically changed the game for the PLM industry. Even if traditional software vendors don’t want to make their applications less monolithic, technology and customers are forcing it.
PLM MICROSERVICES: RESHAPING ENTERPRISE ARCHITECTURE
The change in enterprise architecture technologies has been rapid and broad. The current array of cloud technologies is more powerful and less expensive than the previous generation. It enables companies to store, analyse and actively use data to make decisions and generate new business opportunities.
However, these new tools are also more complex and, in many cases, represent a challenge to well-established enterprise systems and platforms.
Microservices are the big trend in architecture and software development. They attempt to ease the speed and flexibility pain. And it seems they are also popping up in the PLM sphere: PLM gurus Jos Voskuil and Oleg Shilovitsky discuss in their blog posts “Microservices, Apis, Platforms and PLM services” and “Will PLM microservices eat PLM dinosaurs” how microservices are driving the PLM arena towards more agile and flexible architecture.
Microservices represent a fundamental shift in how businesses approach enterprise architecture and software development. In a nutshell, microservices remove business logic from applications and replace it with reusable modules of code that are completely independent from all other parts of the applications.
Let’s explore in greater detail what microservices are, and how they may well disrupt the big PLM platform vendors.
A BRIEF HISTORY OF ENTERPRISE ARCHITECTURE
Enterprise architecture origins: Monolithic applications
Before the 1990s, architecture was strictly monolithic. Monolithic architecture consists of a single application. As we reviewed in “Information systems in PLM”, there are three main building blocks in Monolithic Applications: a database, a server-side application and a client-side user interface. The server-side application handles HTTP requests, executes the business logic, retrieves and updates data in the database, and populates data to the browser.
In monolithic architecture, any changes to the system mean the whole application must be checked out from the version control system, the version must be updated into the server-side application and the whole application deployed.
Software in monolithic applications is not easy to replace piece-by-piece. The constituents of these applications are tightly coupled: if you change something in one part of the program, your action will probably affect other parts of the application. So if you don’t want to “break anything,” you’d rather have your developers have a good mental model of the whole application in mind when making any change.
The PLM platforms widely available today are mostly based on monolithic architecture. They usually support businesses in a proprietary way—that is, they are customized for individual organizations. Such designs make it difficult and expensive for companies to share, consolidate, and adapt to changing business realities.
Decoupling monolithic applications with Service-Oriented Architecture (SOA)
Decoupling monolithic applications with Service-Oriented Architecture (SOA)
Around 2000, there was a shift in enterprise architecture. Essentially, several pioneers arrived at the idea of assembling applications by using a set of building blocks known as components—some of which are available “off the shelf,” and some of which are built from scratch.
They sliced large, inflexible systems into a set of smaller pieces called services. These services exchanged data over the network. The communication between components happened usually via XML.
In SOA, the server defines what functionality can be accessed and what the requests and responses should look like. The interactions are verbs—things you can do with requests to the system—rather than being associated with specific system resources.
Main components of SOA
Web services
“Web Services” are programs that let one application talk to another application over the internet. Imagine you are in a restaurant and order a meal. The waiter takes your order, brings it to the kitchen, and at some point, you get your meal. In this example, the waiter is acting as a web service.
Web services are not tied to any programming language. Coming back to the example, if you speak Spanish and the cook in the kitchen only speaks German, the waiter would take your order in Spanish and translate it to German, so that you get the meal you ordered.
Enterprise service bus (EBS)
In service-oriented architecture, the different software components talk to each other by sending messages. To transport the messages between software components, SOAs typically use an enterprise service bus (ESB).
The SOA registry
The SOA registry is a library where information describing what each component does is stored. Developers and applications consult through the registry to learn which services exist and how they should be used.
Implementation challenges
The challenge with SOA implementations was that even though greater software modularity was obtained, the application pieces were still quite large. Furthermore, by strictly defining how data could be accessed, rigidity was again introduced. Some vendors developed proprietary ways to call methods over the network, which again led to tight coupling.
MICROSERVICES FOR AN ACCELERATED SOFTWARE DEVELOPMENT LIFECYCLE
Around 2010, the term “microservices” was coined. In a microservice architecture, applications are built as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.
APIs are simple interfaces provided over HTTP. APIs are usually built based on REST interfaces, which make data accessible by using the JavaScript Object Notation (JSON) and the HTTP verbs PUT, GET, POST, and DELETE to create, read, update, and delete resources. These protocols and data formats are simpler to use than the web services standards used in the early SOA.
Microservices can be seen as an evolution of SOA. While SOA focused on sharing functionality from the applications, microservices focus more on making the data itself available, without restricting how to use it.
Microservices are very good at consuming data from different sources and transforming it for other applications.
BASIC PRINCIPLES FOR BUILDING MICROSERVICES
1. One microservice, one task
The main principle is that each microservice should only perform one task. In the example below, an application to handle orders is represented. In the microservice architecture, there’s a dedicated service for each task in the order-handling process.
2. Develop and deploy services independently
It should be possible to develop and deploy a microservice independently of all other parts of an application. In traditional monolithic architecture, a change to any single part of the application requires it to be redeployed entirely. With microservices, the application is decomposed into multiple services that can be redeployed independently.
3. Products, not projects
Traditionally, enterprise application development follows a project model – the target is to deliver a piece of functioning software which is then considered to be complete. With microservices, the idea is that software components should become reusable products that a team should own over their lifecycle.
4. Standard HTTP methods for service communication
In SOA, web services communicated using XML. Microservices have adopted modern communication methods such as HTTP, and requests and responses use JSON to describe the data.
BENEFITS OF USING PLM MICROSERVICES
Scalability and Agility through Reuse
In microservices architecture, large software projects are broken down into smaller, more independent modules. Software built as microservices can be broken down into multiple component services, so that each of these services can be deployed and then redeployed independently without compromising the integrity of an application. That means that microservice architecture gives developers the freedom to independently develop and deploy services.
Better fault isolation
Microservice architecture improves fault isolation and enables continuous delivery: if one microservice fails, the others will continue to work, and larger applications can remain unaffected by the failure of a single service.
Support for third-party development
Since microservices represent a small piece of functionality, it’s easier to understand and thus outsource application development. Another advantage is that code for different services can be written in different languages.
Shifting operations towards outcomes
With microservices, there’s a mentality shift. Operations are decomposed and defined in terms of the outcomes. It allows enterprises to visualize the work that functions, customers and suppliers are doing in terms of purpose and activity. Organizations can identify which activities should be kept in-house because they’re strategic and provide a competitive advantage, which ones might be outsourced, and which can be sold as a service for customers.
Better user experience for customer-facing capabilities
Modern web technologies are much more user-friendly than traditional monolithic applications. Making relevant data available through services enables us to use modern web presentation layers and enable end-user app customization, data querying and filtering.
BARRIERS WHEN SHIFTING TOWARDS PLUG-AND-PLAY MICROSERVICES
The coordination challenge: Making sure your microservices play nicely together
So far so good. You are wrapping your ugly code into plug-and-play microservices. But how exactly are you orchestrating all your microservices together to ensure the end to-end service you expect to be delivered? If microservices don’t compose cleanly, complexity is only being shifted from inside a service to the connections between them.
As well as that, it’s hard to figure out exactly where the service boundaries should lie and ensure that the microservices and traditional applications work well together. Any interface changes need to be coordinated between teams, compatibility needs to be checked when updates are made, and testing can easily become more complicated.
This time, who’s going to be the bad cop who helps prevent accidents? A solid governance board around microservices is required if we don’t want to end up creating a jungle, and once again constrain flexibility and agility.
[thrive_leads id=’4222′]
When reuse simply doesn’t happen
The first step to reusing microservices is creating transparency. How do the guys from purchasing know that the guys from manufacturing have already developed an order-handling service? Is there someone orchestrating enterprise service libraries and making sure they are well-understood and available?
We all know that developers usually would rather write new stuff than reuse or modify old stuff. It costs about three times more to create a reusable service than single-use code. Creating reusable microservices is an investment. Again, we come back to governance. Somebody needs to manage a library of corporate microservices and make sure it gets used.
When monolithic dinosaurs and lightweight microservices get married
Traditional monolithic systems, as PLM or ERP, aren’t very flexible. Some of these applications aren’t prepared for modern querying and data-retrieval processes, and you might end up creating big performance and reliability problems. To create effective microservices that use data from these core applications, a great level of expertise is needed. Messing up your enterprise core infrastructure traffic management, monitoring and performance isn’t difficult if you experiment too much.
ARE MICROSERVICES THE NEXT BIG THING FOR PLM?
The ability to offer plug-and-play applications has become an important competitive factor. Fuelled by the convergence of social, mobile and cloud and the growing demand for flexibility and usability, companies need to be agile, flexible, and fast to meet customer expectations.
Jumping into this new model requires a combination of new mindsets, processes and technology. Microservices don’t guarantee a seamless journey, free from business concerns. But they represent a meaningful attempt to move towards a more flexible and modern IT, one that supports the “need-for-speed” in the age of the customer.
Whether microservices are yet another silver bullet remains to be seen. Some suggest a two-speed architecture to develop customer-facing capabilities at high speed while decoupling legacy systems for which release cycles of new functionality stay at a slower pace. However, sooner or later, traditional core systems as PLM will pick up the signals and harness change.
PLM vendors are pressured to step up and play a critical role in supporting businesses to navigate through this transition. Those who envision how the industry will evolve and act accordingly will have great opportunities to thrive and not get disrupted.
[thrive_leads id=’4302′]
