Website Builder



Why Microservices

Microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

MONOLITHIC APPLICATIONS

Key Challenges associated with a Single Silo Monolithic Applications

When looking to split a large application into parts, often management focuses on the technology layer, leading to UI teams, server-side logic teams, and database teams. When teams are separated along these lines, even simple changes can lead to a cross-team project taking time and budgetary approval. A smart team will optimise around this and plump for the lesser of two evils - just force the logic into whichever application they have access to. Logic everywhere in other words. This is an example of Conway's Law[5] in action.

SILOD FUNCTIONAL TEAMS - MONOLITHIC

Leads to Silod Application architectures. Because of Conway's Law.

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

-- Melvyn Conway, 1967

The microservice approach to division is different, splitting up into services organized around business capability. Such services take a broad-stack implementation of software for that business area, including user-interface, persistant storage, and any external collaborations. Consequently the teams are cross-functional, including the full range of skills required for the development: user-experience, database, and project management.

MICROSERVICE APPLICATION

Leads to a Microservice Application Architecture with each microservice mapped into a single process. Can be a stateless or a stateful microservice.

OUR SERVICES


Design

Microservices Design n Migration

Design Microservices as a suite of independently deployable, small, modular services in which each service runs a unique process and communicates through a well-defined, lightweight mechanism to serve a unique business goal.






Architecture

Agile Driven Microservices Cloud Architecture

Microservices is a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services. ... It also allows the architecture of an individual service to emerge through continuous refactoring.

Development

Serverless Polyglot Programming

Develop Microservices using a Serverless ployglot programming model and an environment and what can be containerized and orchestrated to scale automatically in the cloud or anywhere.




Deployment

Container Driven Cloud Deployment Models

Adopt an Agile Continuous Delivery Deployment model allowing for a reliable and cost-effective cloud or your own private deployment.

Microservices Architectural Principles in a nutshell

Just like the Unix philosophy for modular software development, microservices bring the concept of modularity and reusability.


Building small, individual services that do one thing well. These services can be easily maintained and repurposed later by developers.


The purpose of adopting microservices is Scale, Speed, and Agility.

                                                                        Microservices Design Principles

  1. Services are written using a variety of languages, frameworks, and framework versions
  2. Each service consists of multiple service instances for throughput and availability
  3. Service must be independently deployable and scalable
  4. Service instances need to be isolated from one another
  5. You need to be able to quickly build and deploy a service
  6. You need to be able to constrain the resources (CPU and memory) consumed by a service
  7. You need to monitor the behavior of each service instance
  8. You want deployment to reliable
  9. You must deploy the application as cost-effectively as possible