Cloud-based Apps developed using Microservices architecture are a radical change from our present-day Monolithic, on-premise applications. These next-generation applications are providing the software with the robustness and agility it requires in today’s world. These applications are also much cheaper to develop and maintain. Though these applications are economical, they pack a punch! Am I sure you must be mighty intrigued? So let me explain these applications in detail and then we will also discuss how we can develop such a power-packed application.
What do we mean by calling today’s applications “Monolith”?
A Monolith means a single large unit. Today’s Monolithic applications are as depicted below:
The application that you may be having today generally has 3 parts. The first part is the front-end-user interface. It is also referred to as the client part. It is a web interface it will be made up of an HTML page and some JavaScript code running on the client-side machine. The second part is the database, which is a series of related tables. Finally, there is the back end or the server end. The server end is the brains of the operation. It contains all the business logic of the application. A request would first come in from the front end and will be processed by the back end. Whatever information and request come from the front end is first brought to the back end, additional information is then queried from the database, business logic is then executed, the processed information is updated to the database, and request information is displayed back at the front end. Hence the back end becomes like a huge single machine, with one single process doing everything. There are numerous problems with such a structure. As stated before one error can crash the whole application. Hence the application is not robust. Errors are difficult to find and responsibility for failure is difficult to assign. Scaling up is a huge problem. It requires huge instances of the entire application to be created each time. Small changes require the entire application to be changed. These problems are extenuated in today’s environment where we expect the application to continuously change according to real-time requirements. The application is deployed in the cloud and is directly accessible to the user instead of being installed on a local computer. Continuous development is ongoing in real-time as per the requirements of the consumer. It means that there are chances of breakages. Continuous development cannot happen if we have breakages that will bring down the entire system.
Microservices Architecture
The problems stated above have caused a movement toward a Microservices architecture. Microservices are multiple small modular units, designed to do one specific thing. They are completely independent in that they have their own OS, platform, framework, and runtime. All of it is packaged as one single executable unit. It is also independent of the other Microservices.
The way these processes communicate is through platform-agnostic API calls. The protocol is generally Restful state transfer (Rest). These calls generally don’t require the processes to create a state. Thus processes don’t lock out. Because the calls are platform agnostic, the developers can independently develop separate processes in the platform they are comfortable with or is more suitable for that particular process. With cloud apps, the infrastructure itself becomes lines of code. This gives the developers immense flexibility. The cloud is also enabling container technology. The containers have both the OS and the line of executable code to run on the OS. Now developers are using the two (containers & cloud) to create code that is on their own platform and language. There are many benefits to this architecture. Scaling out becomes much easier. Instead of creating multiple instances of the whole application, it is now possible to create multiple instances of the particular services that require to be scaled. The overhead of creating additional virtual machines is avoided. New processes can run on the same virtual machine. Fault tolerance increases much fold because each process has been separated. Now the failure of a particular process doesn’t affect the other. Lastly, by adopting microservices, you can invest in reusable building blocks that can be in continuous development. Each microservice becomes like a Lego block that can be plugged into an application stack. By investing in a set of core microservices, you can assemble them to build cloud apps catering to a variety of uses. Also because it is hosted on the cloud and is highly robust, you can keep the app in continuous development.
How to develop cloud apps using Microservices?
Now one can easily take an app to the cloud without venturing into a microservices architecture. If you do so you can immediately gain the benefits of getting hardware flexibility and cost savings. However, this is the only fraction of the benefit possible with the cloud. It is a very sub-optimal use of cloud computing capability. In such a scenario an approach proposed by folks from Carnegie Mellon University is “the horseshoe.”
As the picture above shows, one should begin at the Technical Architecture level to start a cloud app development. Migrate to the cloud your existing app. Then you can proceed to change the application itself making it microservices oriented and thereby making changes at the architecture level. As we move up each level the path becomes longer and costlier. But, this way old legacy system which has become gridlocked for change, due to it containing critical code, for which expertise has gone away due to retiring personnel, can be unlocked and changed to a modern cloud app.
Have questions? Contact the cloud computing experts at InApp to learn more.
