How microservices bring agility to SOA

Break up the monoliths

The concept of breaking monolithic applications into smaller applications began with SOA, in terms of breaking applications into modules and then to smaller services, said Andrew Leigh, vice president of product marketing at Jitterbit. Microservices is a hodgepodge of terms that all mean to enable big monolithic applications. "Everyone knows they want to break up systems into individual processes and service enable those processes and tasks inside and outside the firewall," explained Leigh.

Now mobile applications are small, purpose-built applications for a specific task, and that task needs to extract data in a specific process that lies behind the firewall. Organizations need to think about integrating not to the monolithic ERP application, but to APIs for the order entry module or pricing module. But there is still a need to integrate into the back office systems that hold the bulk of enterprise data, said Leigh. For example, a salesperson just needs information about the last 10 orders for a customer, rather than every order. The service needs to still be able to go to the back-end systems and pass data not just to one sales rep, but to 10,000 sales reps.

One challenge in implementing microservices has been getting organizations to understand the concept that an application becomes completed, distributed and not monolithic, said Jeff Genender, principal and founder of Savoir Technologies Inc., an open source SOA consultancy. "Many developers still believe applications are deployed in a single directory or as a fully packaged container," he said.  "It's sometimes tough to get people to break that a paradigm. Once they do, it's fun to watch the lights turn on and get that 'ah ha' moment."

Focus on agility rather than reuse

Ed Anuff, vice president  of product strategy at Apigee Corp., said many people have been using the term microservices which essentially means classic SOA, rather than embracing a new style of developing applications in order to escape from the connotations of SOA as being dated. But he believes that the microservices philosophy empowers more Agile development practices rather than the enterprise-wide reuse espoused by standard SOA.

Classic SOA was oriented around creating an organization wide architecture to make sure people across the organization could reuse resources, and leverage the investment in one place across five others. Getting a high-level of reuse requires thinking about creating the right level of abstraction, which can tie different systems together across silos. With classic SOA, services tend to be defined in company-wide architectural strategy meetings. In this context, components of microservices  that have  potential for wider reuse across development teams might be wrapped up with more service definitions for an enterprise standard.

Microservices tends to be focused on agility rather than reusability, said Anuff. A microservice can evolve into a classic SOA service, but microservice development tends to start with a particular application rather than planning for enterprise requirements and edge cases. The microservices approach is better suited for one application team using APIs within the application to split things apart and scale services differently.

Finer grained scalability

With traditional software development lifecycles, development has been focused on writing applications in a monolithic way in a single app server. This is an artifact of the Java world where an app server would load up a bunch of components and use something like a Spring framework. "The problem is that as these applications are scaled up, different pieces of the application end consuming different amounts of memory or CPU," Anuff said.

The microservice philosophy also gives enterprise architects a framework for thinking about how to break the application in a way that makes it possible to scale different pieces of the app. One good approach is to break the apps into separate containers in a way that enables intra-application communication rather than inter-application communications used in classic SOA, said Anuff.

With microservices, the smallest unit of the computer is a little Docker container running 10 lines of node.js.

This makes it possible to implement something like a product lookup service, which queries three tables in database for a specific piece of user interface in a containerized way. This simple service can scale independently without breaking the other part of the applications that might be generating reports.

Rectifying the SOA Legacy

Microservice principles align closely with trends in Agile software development and perhaps the evolution of SOA principles, minus the heavy weight of traditional enterprise service busses. Haddad noted that one of the constraints of a microservices approach is that services need to be implemented in atomic silos so that they can be operated on independently. "This concept tends to torque up enterprise architects that have taken a big picture view and are interested in performance and a cross domain view and modeling that effectively," he noted.

The problem is that enterprise architects with established enterprises are working with lots of commercial off-the-shelf (COTS) applications that are big and monolithic. This makes it challenging to recognize how architecture from a microservice approach can rectify investment in architecture and high-performance applications.

For example, an enterprise COTS application inhibits a microservices approach because it bundles in multiple business capabilities. "You don't have a separate stack between time card and payroll or between order and invoice. It is all just one monolithic application," Haddad said.

While it is possible to factor out two separate microservices for order and invoice, this approach limits the implementation of the microservice paradigm. The problem is that the order and invoices cannot scale independently because they both point to the same backend application. "The whole premise of microservices is to spin up multiple back end services, and separate out the solutions stack between different service entities, so that when they fail, they don't take the other ones down, and also that they can scale independently," Haddad said.

At the end of the day, Microservices are not necessarily something new, but merely SOA done right. According to Genender,  "We have been building microservices as ESB or SOA endpoints for many years.  Microservices is just a new term coined for SOA back ends.  SOA and ESB terms have had bad connotations to them due to the botched implementations, the corporate hype and the misuse of the terms to mean 'too many different things.'"