Microservices and the Evolution of Service-Oriented Architecture

Mike Piech, VP & GM Middleware, Red Hat

Mike Piech, VP & GM Middleware, Red Hat

Service-oriented architecture, or SOA, refers to the software development practice of building applications out of reusable services rather than engineering duplicate functionality into distinct programs. Although the term SOA has fallen in popularity since its coining in the early 2000s, the underlying concept continues to influence software development.

Mike Piech, Red Hat's vice president and general manager of middleware, discusses the evolution of service-oriented architecture over more than a decade and shares his views on how it has shaped and been shaped by mega-trends from mobile and cloud to big data and the IoT (Internet of Things).

Relevance of SOA

Breaking down monolithic applications into loosely-coupled sets of independent modules that are easy to update and scale is simply good engineering practice. Software engineers were modularizing applications long before the term SOA was coined. The term SOA emerged in the Web 2.0 days, once the web became a viable user interface for enterprise applications and web clients could interact with server-side proxies that could then aggregate the data sources and computational capabilities of multiple different modules.

Evolution of SOA concepts

Over time, SOA has become finer grained. Software engineers and technical architects have modularized services even further into smaller and more narrowly scoped pieces—now commonly referred to as microservices—which perform even more focused functions. Engineers didn't initially break down services with such granularity because developing, deploying, u p g r a d i n g , visualizing, and managing such large numbers of services was intractable using first generation SOA infrastructure and tools. But as virtualization, PaaS (platform-as-a-service), and the cloud have made it easier to stand up and take down individual services, and as virtual machines have evolved into lighter-weight containers, development at a very granular level and management of a huge number of services have become practical. The promises and benefits of SOA can now extend through the service and application lifecycle.

The role of microservices and containers in SOA

Microservices and containers are the logical continuation of the idea behind SOA. They provide greater flexibility in terms of how software engineers can build and optimize architectures to solve problems. This is not to say that everything

will be or should be a microservice going forward. For example, complex financial transactions with currency movements might never be subdivided into microservices because of the need to maintain transactional integrity and store logic and data together in a single module. The distinction between service and microservice is all a matter of where you draw the line in terms of size. Either way, employing lightweight containers carrying lightweight pieces of logic that are decoupled from the architecture and focused on performing a single function will always benefit certain applications.

SOA explosion: Impact on mobile applications and devices

The widespread adoption of SOA has been symbiotic with the explosion of mobile applications and devices. The more modularized the application back-endsand the more different services available, the more opportunities exist for developers to creatively combine those elements into whole apps, mini-apps, or even micro-apps. Our idea of software has evolved from the desktop concept, where an application is a large, comprehensive entity with many possible use cases, to the mobile concept, where an app is smaller, lighter weight, with fewer use cases. SOA has catalyzed this evolution by providing services that are granular enough for engineers to fuse them into applications that are small enough to support the mobile concept.

SOA: hub-and-spoke or fabric approach

Fabric; our customers are increasingly moving toward a fabric approach, and many areas of development in upstream communities are fabric-oriented. Customers and developers alike are transitioning away from centralizing logic and control as was common in t r a d i t i o n a l enterprise service bus (ESB) implementations and moving to a more distributed service-oriented architecture.

“In the hands of a savvy developer, SOA and microservices are powerful tools that can enable greater flexibility and optimization in architectural choices”

Meanwhile, the use of messaging is on the rise. You still see hubs, but you see many more point-to-point setups—more sub-hubs, as it were, instead of a single centralized hub-and-spoke. The arrival of big data and the Internet of Things has flooded networks and applications with data. Handling such a huge amount of data within a single, central hub has become unmanageable and has forced the fragmentation of centralized entities.

Open source: relevance in SOA

At Red Hat, our experience has been that innovation occurs much more rapidly in open source communities, which is part of the reason why any enterprise considering SOA should be following open source communities. Consider for how many years hub-and-spoke, centralized-style architecture was the norm in enterprise software development. Now consider how quickly containers and Docker have burst onto the scene. The pace of innovation in SOA is accelerating, driven in most cases by open source. I believe that you can only keep up with that pace by harnessing the combined creative power of the larger community that open source leverages. To give another example of how open source has propelled innovation in SOA, look at Apache Camel and Apache ActiveMQ, two open source projects that have become extremely popular for building SOA solutions..

Pitfalls of SOA

With any technology, the biggest pitfall is “shiny object syndrome,” where you try to use an exciting approach, ubiquitously, as if it's the only way. Some functionality makes more sense to be more monolithic and less modularized, but there's the danger of engineers breaking down services into tiny microservices without any purpose. Sometimes larger groupings of functionalities are easier, more efficient, and more tractable to develop and maintain.

Advice for companies considering SOA

Ultimately, you need to modularize services in a way that addresses the problem, anticipates software lifecycles, and offers appropriate scalability. In the hands of a savvy developer, SOA and microservices are powerful tools that can enable greater flexibility and optimization in architectural choices.