Software architecture continues to evolve over time as new trends and technology advances emerge. In the 1980s the focus was on transactional systems running on mainframe computers. In the 1990s the personal computer brought about client/server applications. 
In the 2000s, data distribution and synchronization along with the growth of the internet reduced the role of core transactional systems. Today, the focus is on device-independent software that can be reached from anywhere and can keep up with the changing needs of the user. This gave birth to a new architecture called microservices.
So what are microservices? Essentially, they are a set of narrowly focused, independently deployable services. While they evolved from the service-oriented architecture (SOA) that came about in the 2000s, microservices are different from SOA in that the latter aims at integrating various applications whereas microservices belong to one application. Each microservice runs in its own process and communicates using lightweight mechanisms, usually an HTTP-based API. Microservices are usually contrasted to monolithic applications, where the architecture is focused on logical components and layers, not separate physical components. For instance, here are some microservices that I am currently working on as part of writing a compliance system:
At Kingland, we use automated deployment machinery to continuously update our application servers. With a large monolithic application we would have to redeploy the entire application in order to update one component. This would interrupt background tasks and potentially create downtime for the application. Since components that haven’t been updated also would have to be restarted, the risk associated with redeployment increases, which discourages frequent updates. With microservices, each service can be deployed independently of other services, making it easier and less risky to deploy application updates frequently.
We deploy many of our applications to the cloud, leveraging its elasticity and scalability capabilities, as well as its global reach. We see the cloud as a key enabler of this architecture pattern. The dynamic nature of cloud platforms allows us to spin up (or tear down) and connect new instances of our microservices as user load changes.
Much of the front-end development these days is done with responsive frameworks like AngularJS. These frameworks enable a rich, interactive and dynamic user experience on a variety of clients including mobile devices, and make their server requests through AJAX calls. A perfect match for microservices, with their RESTful HTTP-based API.
In my mind, microservices also help us make better technical decisions. It makes us decompose the solution into distinct business capabilities and stay true to the separation of concerns design principle. You can also avoid making certain application design decisions up front, allowing work to start and better decisions to be made later in the project. And since each microservice is a separate executable, it can be based on different technologies, allowing us to pick those that are best suited to address the individual requirements and allow change to new technologies on a component by component basis.
Many of our projects these days are using an Agile approach to iterate rapidly and deploy software frequently. The narrow focus of each microservice helps keep the tasks small. This is an important quality for iterations to be short yet produce a working product (albeit not necessarily full featured) at the end of each iteration.
Are you ready to draw the benefits from microservice architecture in your software products? Tell us below.
1401 6th Ave South, Clear Lake, IA 50428
1-641-355-1000
Comments (1)