Cloud computing has forever changed the way we build modern applications. Cloud gives developers an ability to provision necessary services for their applications at the click of a button without having to worry about the underlying infrastructure. Fast, Agile, In-expensive and massively scalable infrastructure with pay-as-you-go billing offered by cloud can tremendously improve operational inefficiencies and helps reduce upfront costs.
Traditionally developing, maintaining and enhancing large scale applications required huge upfront investment in the infrastructure and people with specialized skills in configuring and managing that infrastructure. You need to have separate teams for managing servers, databases, service bus etc., and different teams for developing applications. This resulted in having multiple teams working in silos and they would have little to no communication during the development cycle.
Applications written using traditional three tier architecture were inefficient and made it very difficult to introduce changes. Since all the different pieces of the application tier are tightly coupled with each other, any change to an application service, however small, required the entire application tier to be retested and redeployed. This increases the development cycle and makes it very risky to introduce new changes quickly.
Any changes to the application architecture to improve performance like adding new cache tier introduced new risks, raised costs and created additional complexities and increased development time. Teams wouldn’t risk disturbing existing architecture for the fear of introducing new risks. Agility is lost. Teams cannot innovate quickly or rapidly introduce new features.
Cloud solves that!
With the advent of cloud, the emphasis has shifted towards agility. Major Cloud vendors like Microsoft introduced platform-as-a-service features where services can be provisioned and configured at the click of a button. This completely eliminated the need for infrastructure teams as this can be done easily by developers. Developers can have complete control of the application code as well as the services it consumes, while the underlying infrastructure was managed by cloud platform providers. It also gave the developers the power to try new software development patterns to reduce inefficiencies and improve agility.
Cloud makes it possible to breakdown the monolithic applications into smaller set of services (micro-services) and paved the path for building hyperscale, highly-available, agile, fault tolerant applications rapidly and at a fraction of the cost it would normally take with traditional application architectures.
Microservices is an old software architecture paradigm where the functionality of an application is divided into smaller set of individual pieces of business functionality (services) that are independently developed, deployed, and managed by a small team of people. It provides a way to break up large monolithic applications into smaller more modular pieces with the goal of reducing complexity.
Although it’s an old concept, it rose to prominence recently with the advent of cloud computing. Cloud makes it very easy to develop applications using Microservices without upfront investment in infrastructure. Many cloud vendors have offered their own flavor of microservices and Azure Service Fabric is Microsoft’s platform that makes it easy to package, deploy, and manage scalable and reliable microservices.
It provides set of APIs, data structures, libraries and the tooling required to build large scale applications using microservices.
What exactly is a Microservice?
Microservice at it’s core is a service with a very narrowly focused capability. It does one thing and one thing only to satisfy a business capability. Each microservice is self contained and fully independent. They communicate with other microservices via established protocols and can consume events published by other microservices or publish their own events for other microservices to consume.
Microservice has the following characteristics :
- Each microservice is responsible for providing a singly business capability
- Each microservice is individually deployable.
- Each microservice is individually scable.
- Each microservice consists of one or more processes
- Each microservice exposes an external interface (RESTful API) for other microservices to communicate with it.
- Each microservice can publish or consume events.
- Each microservice can usually be developed by a small team that has the knowledge of the business capability it provides.
- Microservice can communicate with other microservices in a synchronous or asynchronous way.
- Each microservice should be easily discoverable in a cluster using naming service. Azure Service Fabric provides the framework to develop microservices that satisfy the above criteria. It provides support for the full application lifecycle management of cloud applications. This lifecycle includes development through deployment, daily management, and maintenance to eventual decommissioning.
Once the application goes live, you can monitor the health of your microservices using a neat fabric explorer provided by Service Fabric.
Here’s the view of fabric explorer for one of my clusters.
As you can see, Service fabric provides a neat way to monitor the health of the microservices deployed to the cluster. It provides automatic fail-over to a different node should something fail on the node where the services are running. It also provides an easy way to increase services instances when the load increases or decrease the instance count during off-peak hours. Service fabric is really powerful and it abstracts away all the complexity in building microservices based applications and provides an easy to use framework served on a platter, so you can focus exclusively on your business logic.
Over the next few days, I’ll dive a little deeper into building truly planet scale applications using Azure Service Fabric and show you how to leverage many of it’s inbuilt features with real-life examples.