DeveloperWeek 2015: Dev techies unite in San Francisco
Reporting and analysis from IT events
The rise of cloud infrastructure has made it possible for enterprise architects to consider a new style of application development called microservices. The basic notion lies in thinking about creating applications built around business domain components, which can be developed, managed and spun up separately. Cloud infrastructure and platforms make it easier to deploy, manage and interconnect service functionality used with microservice in discrete components
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
"Microservices is about taking the organization's services portfolio and decomposing them based on business domain function," said Chris Haddad, vice president of platform evangelism at WSO2, and former Gartner Analyst. “It is a business domain first look at the service portfolio."
The concept of microservices emerged in 2012, and was popularized by software author Martin Fowler, who acknowledged that there is no precise definition of this architectural style, although there are common characteristics around business capability, automated deployment, intelligences in the endpoints and decentralized control of languages and data.
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.
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.'"
Get an introduction to the world of microservices and container technologies in this essential guide.
How will SOA keep up with the connected-everything trend?
What you need to know about testing microservices