Building Modern Software Applications with Microservices

Before the advent of microservices there existed mostly what is known as a monolith application. An all-encompassing application that is designed, built, tested, and deployed job done or maybe not. Of course, this is exactly why 80% of all software projects ultimately failed. Especially in a world where nothing sits still and requirements are constantly changing and evolving. Even if the monolith was built to perfection 9 times out of 10 it becomes obsolete almost immediately it is released into the wild. The process of updating such an application can be extremely difficult because the team that built the application has moved on technologies have changed etc. It is usually easier to just start again and build something new to meet new requirements and then we go through this cycle again of releasing something that's obsolete.

A modern era has finally dawned and the process of developing and delivering software has changed. Ultimately software is being delivered in a way that it can continually evolve and change according to the needs of the business. It is never finished but ever-changing because the competition is changing and we need to adapt and take advantage of new opportunities or implement new regulations. Applications are now built on a concept of Microservices where instead of a single monolith we have multiple independent features working together. Each feature with the ability to be updated/removed without impacting the ability of other features to continue working. This goes all the way from the user interface (UI) being made up of small independent components to the services that satisfy the needs of the UI through to the multiple databases that house the data of each individual feature or service. Well, maybe it is not so perfect nothing ever is but it's certainly much better. Software is now being built to evolve and it can only do so when dealing with small components that are easier to implement/update/remove and deploy. Ultimately there will still be some interdependencies and managing change is still difficult and complex but it's certainly more manageable.

You could think of it as the decentralization of power. Rather than everything being done by one big application, different requests are handled by different specialized components to serve a common goal.




SCRUM, Software Delivery, Developer, QA and Lover of life.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

SQL Injection with Kali Linux

How to Use Jupyter Notebooks as Modules

Millimeter Island

The Benefits of Technical Sparring

About SQLite.swift

Kafka for Developers — Part 2 — Spring Boot and Embedded Kafka

UML Diagram. Meter class has methods start() and stop() and attribute of MeterReadingSender, with two implementations.

How Power Rectifiers Works For Clients

TFLite Micro vs GLOW AOT

Miscellaneous Microcontroller development boards

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


SCRUM, Software Delivery, Developer, QA and Lover of life.

More from Medium

Migration to Microservices : What to watch out for ?

1. Microservices foundation

On Service Health Checks

CNCF and beyond