Software is modular again. Intro to microservices.
Microservices is a way of building applications as smaller chunks of services each doing independent self-contained work (as opposed to a single large monolith that does many things).
Microservices are usually implemented following REST principles. It means that a software module to be called microservice, it should follow some patterns — patterns like service not having to keep track of the state of application (state is just a nerdy term for data) or multiple services not having to exchange state changes to each other creating inter-dependencies.
In it’s previous avatar known as SOA, services were modular but didn’t have this restriction of REpresenational State Transfer (REST). One of the ways to isolate state within a microservice is called Domain Driven Design.
Endpoints
A microservice might display the contents of a webpage, return the result of a user request (like clicking on OK button) or store information that user inputs on a form. A microservice might do just one of these tasks, or a few of these tasks. The important point is that each of these tasks has an endpoint.
An endpoint is represented like this: /products/product-onion-details
or like this /onion/{id}. When making an HTTP request to fetch a specific instance of onion we use GET /onion/{id} and to update we use PUT /onion/{id}.
Endpoints are two things. (1) They are an entry point for a requestor (a client making a request over browser or another service making a request) — the front door of a communication channel. (2) They represent the resources that a microservice use — essentially the location on a server that holds the resources.
When we call out to these endpoints from the browser (as a result of your point and click operations on screen for instance) the endpoint would look like this combined with the domain: www.myweb.com/products/product-onion-details.
Why microservices?
Developing modular software has always been the foundation of software architecture, it’s nothing new. Microservices became predominant because applications transitioned from arcane client-server apps to web apps that are delivered through a browser or smartphone app that has hundreds to millions of users. Billions of people now has knowledge and access to software — amazon.com, netflix.com, google.com are all software. This transition demanded scaling out at least certain components of applications more than others.
For instance an e-commerce application (like amazon.com) would need to scale out it’s product search service for consumers more than it would need to scale out it’s new-product listing service for 3rd party merchants. With microservices one can deploy each of these services as independent units into a container (like a docker image) and scale them independently (100 product-search containers, only 10 new-product-listing containers, perhaps 50 payment containers — each possibly running on a different machine).
Where is it headed?
Wild adoption of any new software development tool (eg: programming languages, APIs) or technique (eg: microservices, CI/CD) eventually results in creation of platforms that commoditizes the original tool or technique. Ruby resulted in Ruby on the Rails. APIs resulted in Mulesoft, Apigee and cloud-hosted API Gateways. Microservices resulted in Kubernetes. CI/CD and Agile resulted in Jira/Jenkins/many others.
There is a deluge of integration platforms (some of them mentioned above) that orchestrate, scale and integrate an enterprise’s services. Add to that the need to manage it across on-premise servers and one or more public cloud providers.
In the past (about 15 years ago) we had 2 or 3 well known middleware companies (TIBCO!) that did application integration and message passing for the entire enterprise. They all sat in an on-premise data center and we never called them on-premise because nothing was off premise ever! It’s hard to predict what’s next but there are interesting things from webhooks to web bundles that could influence how we write our services in the future.
