A mobile application has very little function without data to work with and enterprise business mobile applications, even more so. This has given rise to the visibility of application programming interfaces or APIs within the enterprise. Businesses are using APIs to allow visibility to certain business data to business partners outside the company. This concept is nothing new, businesses have been sharing data through Electronic Data Interchange (EDI) and Value-Added Networks (VANS) since the 1980s. However, in the last two years, the spotlight has again shown on APIs as the linchpin to support mobile development.
One facet of creating APIs to support mobile development is Microservices which are small, single-purpose, server applications and that can be composed together to form other server applications. The idea is that a microservice does one thing well and executes as a standalone application within a server container (which is one of the differentiators between microservices and their larger SOA brethren). A number of IT technologists have equated microservices with the idea of Unix shell pipeline apps in that they share characteristics such as “small”, independently deployed in their own container, may communicate with each other and are loosely-coupled. James Lewis and Martin Fowler of Thoughtworks published an excellent paper that covers Microservices 101:
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.
You can say that the above statement could also fit SOA but Lewis/Martin call out how microservices are different enough to stand as its own architecture.
One of the reasons that microservices is a popular choice for mobile development is that each service can start out small, the developer can work both sides of the effort, creating both the mobile app and the service to support it, iterating the services to meet the needs of the mobile app and simply deploy the changed service without coordinating with other developers or the service development team.
This leads into the second trend besides mobile development that has pushed Microservices to the forefront which is the shift to DevOps and Continuous Delivery as another key enabler. The reason for this is that microservices support the need for quicker, independent development (no teams), easy rollback, developer-owned (no handoff to the service support team, it follows more of the “you built it, you support it”), and frequent releases.
Microservice allows an easy and flexible way to integrate automatic deployment with Continuous Integration tools familiar to developers such as Jenkins. That is not to say that microservices provide some type of free-lunch; once the size, number and complexity of the services move out of infancy, a number of issues need to be addressed including operational overhead, a higher level of DevOps skills and the complication of managing a large number of services, many of which perform some level of service inter-communication.
SOA has been around for quite a while and it is difficult to remember when it was the new kid on the block. For the most part, service development around REST and the JSON data interchange format has taken hold and microservices has made it easier for the mobile developer to easily and quickly build/deploy the services needed to support a mobile application.
Microservices as a Mobile Development Enabler
by Perry Hoekstra on August 26th, 2014 | ~ minute read
