Microservice Architecture: Is it All Just Hype or Something More?

The latest trend in software development is microservices architecture (or just microservices). It’s an architectural concept that resists the monolithic approach to application architecture.

Microservice architecture is essentially a method of building software applications as a collection of small, independent, deployable, modular services where each service runs a unique and independent process that communicates through a lightweight, well-defined mechanism to serve enterprise goals.

These services utilize HTTP/REST (Representational State Transfer) with JSON or Protobuf to communicate with each other depending on the application’s requirements. DevOps experts are free to choose whatever communication protocol they like, but more often than not, they choose REST as it’s less complex than similar protocols.

What’s more, the only dependency you have to deal with is making sure that the API used for each microservice is compatible or uses the same message broker.

So to orchestrate different microservices to run the applications, containers (like Docker or Kurbernetes) can be utilized. Some other tools like Apache Mesos (which is cluster manager) or an orchestration solution like OpenStack Heat can also be used effectively.

Check out: How to Keep Your Software Containers Secure 

So this method ties together the bounded contexts of the app, bounded context in each microservice, and each microservice in its own server. As a result, businesses can benefit from increased speed, scalability, resilience, and agility when they take the microservices approach to development.

It’s also particularly a great option when you have to enable support for a wide range of devices and platforms. This means that it will make it easier to support the following:

• Internet of Things (IoT)
• Mobile
• Wearables
• Web

Great examples of enterprises that have embraced the microservices approach are as follows:

• Amazon
• eBay
• Netflix
• PayPal
• Twitter
• Uber

What are the key advantages of using microservices?

If you compare microservices with traditional application development, you can easily see what all the hype is about. The traditional approach to application development follows a sequential non-iterative development method, however, microservices follow an agile development methodology.

As each microservice will be developed separately and simultaneously solving smaller pieces of the overall puzzle, you also have the opportunity to write code in different programming languages (along with different storage methods).

Furthermore, you might have to only upgrade an individual module rather than upgrading the whole app. So when it comes to scaling the app, only the microservice that requires scaling needs to be distributed and replicated (whereas the traditional approach would have required you to upgrade the entire app).

The same applies to scaling an app as only the microservice that requires scaling has to be replicated and distributed (and not the whole app!). You also have the option of using individual microservices to be shared or used by other apps (which has the potential to significantly boost your ROI).

Microservices architecture often exists in open source modules, as a result, development teams don’t need to start working on a project from scratch. Instead, they can simply customize an available open source microservice or use it as is.

Once the build is complete, microservices will be deployed separately. This approach can make the application much more resilient. What’s more, if one microservice fails, a new one can be deployed rapidly (or automatically) without affecting the overall application (and because they’re tiny, replicating them will be quick and simple).

What are the disadvantages of using microservices?

While the hype that surrounds microservices is totally justified, it’s not for everybody. This is because the microservices architecture approach requires traditional organizations to completely change the way they think, collaborate, and operate.

It also requires a leader with a vision of how all the modules will come together to achieve the end goal. Furthermore, services will also have to be developed with a very real possibility of failure and multiple teams will also have to collaborate effectively.

Ideally, services will need to be developed in a manner where failure doesn’t cascade to other services. But to achieve this, it will require a lot of planning along with continuous real-time monitoring.

If you use APIs, you will also find that it requires remote calls and that’s much more expensive than in-process calls. All these disadvantages combined will make it difficult for smaller businesses to get into the game. However, this new phase of app development is definitely exciting and one worth exploring.