Abstract

Those days are gone when an enterprise was happily serving its customers by just a handful of on-prem servers, delivering content within seconds to minutes, thinking hours of downtime for maintenance and deployment is fine and data consumption is in gigabytes.

Today’s distributed systems are meant to serve an ever-expanding number of customers “Anytime, Anywhere, on Any Device“, customers expecting a response in milliseconds and 100% uptime. Users expect millisecond response times with 100% uptime, and data is measured in Petabytes.

Today’s demands are simply not met by yesterday’s software architectures.

To meet such enlarged expectations, our distributed systems must be Responsive, Resilient, Elastic and Message Driven, and this is called a Reactive System. Systems built as Reactive Systems are more flexible, loosely-coupled and scalable. They are significantly more tolerant of failure and when failure does occur they meet it with elegance rather than a disaster.

Four Reactive Principles

Responsive: The system responds in a timely manner if at all possible. Responsiveness is the cornerstone of usability and ensuring early problem detection and resolution. Responsive systems focus on providing rapid and consistent response times and delivering consistent quality of service. This consistent behavior, in turn, simplifies error handling, builds end-user confidence, encourages and promotes continued interaction with the software application.

Resilient: The system stays responsive in the face of failure. Any system that is not resilient will be unresponsive after a failure. Microservice Architecture lays the foundation for building a resilient system. Resilience is achieved by isolation, replication, and containment, Failures are contained within each component, isolating components from each other and thereby ensuring that parts of the system can fail and self-heal without compromising the system as a whole.

Elastic: The system stays responsive under varying workloads and increased demands. Reactive Systems can react to changes in the input rate by increasing or decreasing the resources allocated and support the business continuity. This implies designs that have no contention points or central bottlenecks, resulting in the ability to shard or replicate components and distribute inputs among them.

Message Driven: The system relies on asynchronous message-passing to ensures loose coupling, isolation, location transparency, and provides the means to delegate errors as messages. Asynchronous messaging supports nonblocking communication which allows recipients to only consume resources while active, leading to less overhead on the system due to non-blocking I/O.

Are You Cloud-Native?

December 11th, 2019 | Posted by Vidya Vrat in Architecture | Azure - (0 Comments)

Introduction

Cloud-native is an approach to build applications using microservices, containers, Kubernetes, DevOps, CI/CD, and cloud (public, private, hybrid). With this great combination of great architecture, platform, culture, dev practice, and cloud-computing model your applications will be built for scale, continuous change, fault-tolerant, and manageable. Let’s explore and understand each of the key players in the cloud-native approach.

No alt text provided for this image

Microservices

 Microservice is a small autonomoustightly scopedloosely coupledstrongly encapsulatedindependently deployable, and independently scalable application component. Microservice has a key role to play in distributed system architecture. 

No alt text provided for this image

Microservices architecture offers a lot of benefits, but there is a cost involved. You may want to learn more about its advantages and disadvantages by following the link https://www.linkedin.com/pulse/microservice-architecture-vidya-vrat-agarwal/

Containers

A container is a standard unit of software that packages up code and all its dependencies, so the application runs quickly and reliably from one computing environment to another. A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries, and settings. Containers provide an abstraction at the app layer that packages code and dependencies together. 

No alt text provided for this image

Kubernetes (K8s)

Kubernetes was born from Google’s over 15-year experience running production workloads. It is designed to grow from tens, thousands, or even millions of containers. Kubernetes is a container runtime agnostic. Kubernetes is an open-source container orchestration tool designed to automate deploying, scaling, and operating containerized applications. “Distributed Management and Orchestration “of containers is an integral part of making your application cloud-native, and Kubernetes does it all.

DevOps

DevOps is NOT a “Packaged Solution”. I.e. You cannot buy and install it.

No alt text provided for this image

DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.” – Donovan Brown, MSFT. DevOps is a “culture” (Agile is a mindset), where development, test, and operations work together in a collaborative manner to automate the delivery of quality software. DevOps culture develops a “production-first mindset”. I.e. applying DevOps ensures that your code is always ready to be deployed to production 

No alt text provided for this image

DevOps breaks the wall of confusion between teams and fosters better communication and collaboration throughout the application development lifecycle and results in better visibility and small frequent deployments together.

You can learn more about DevOps here https://www.linkedin.com/pulse/devops-what-why-how-vidya-vrat-agarwal/

CI/CD

Continuous Integration (CI) and Continuous Delivery (CD) enables and empowers any software delivery team in an organization to continuously deliver value to their end-users.

With CI/CD practices in place, development teams are more likely to commit code changes more frequently, which leads to better collaboration and software quality.

Continuous Integration (CI)

CI is the process through which the building and validation of developer code are automated to ensure quality check-ins. You can build a CI/CD pipeline in the DevOps tool of your choice, and for cloud-native it will not be complete unless you have an important step “push the image to container registry”. Here, is a visual of how CI phases look like in Azure DevOps (previously known as VSTS).

No alt text provided for this image

If you are interested in building your own CI/CD pipeline using Azure DevOps then you can read more by following the link https://www.linkedin.com/pulse/building-cicd-pipeline-from-scratch-azure-deployment-using-agarwal/?trackingId=2ZXCXz7mpm8mnjAQB8BF7g%3D%3D

Continuous Delivery (CD)

CD picks up the package built by CI, deploys those into multiple environments like Dev, QA, staging, etc. then runs various tests such as integration tests, performance tests, load test, etc. and if all works fine then on a button click it can be finally deployed into production.

No alt text provided for this image

Summary

While each of the above serves tremendous value in its own entity, but if all the above combined together then it will contribute towards a true cloud-native approach. Imagine using benefits of cloud, microservices, containers, Kubernetes, DevOps, CI/CD combined together, which unlocks the formula to the success of any organization that want to reap the multifold benefits to the health of software, delivering value to the customers, support demand at scale, and lowering the development and operational cost of the application.

If you are not cloud-native yet, then you may be interested in knowing that by 2025, over 80% of enterprise apps will become cloud-based (source: forbes.com) or be in the process of transferring themselves over to cloud-native apps. Are you?

I spoke on “Microservices as a Product” at #productschool Bellevue WA on Oct 30th, 2019 Wednesday 5:45 pm – 7:45 pm. This was a #FREE session  https://lnkd.in/gAdS2fT 

No alternative text description for this image

Please find the content here at my #github https://lnkd.in/gwTDFfi and Recording at my #youtubechannel https://lnkd.in/gjFxnH3 or here below

On Sep 14, 2019, Saturday, I spoke at #SeattleCodeCamp (this was my 4th year in a row). Both of my sessions were unique in nature, simple to follow, and heavy on core concepts, and practical implementation. 
1- Writing code with a product mindset. – Pigott Room #306 8:30-9:30am
2- Real-world examples of MicroService Architecture and Implementation. – Pigott Room #205 11-12pm 
This was a FREE Tech Community event available to be registered at https://lnkd.in/eM-tzVs 

You can find the decks here at https://lnkd.in/gXCn8Rs

Other Articles you may find helpful: https://lnkd.in/gGzSWbV https://lnkd.in/gBAZc7t

No alternative text description for this image
No alternative text description for this image

An evening on Thu Aug 8th, 2019 well spent with people who appreciate the knowledge and aspire for learning. Thanks again City University of Seattle Clark Jason Ngo and Sam Chung for having me to talk about “Microservices Architecture”

No alt text provided for this image

Microservice Architecture

May 13th, 2019 | Posted by Vidya Vrat in .NET | Architecture - (0 Comments)

Abstract

The microservices architecture style is an evolution of the Monolith SOA (Service Oriented Architecture) architecture style. The difference between the SOA and microservice approach is how these are being developed and operationalized. With every new technology addition, our responsibility also increases to be abreast of pros-and-cons the new member has, and the pain points it is designed to solve.

Monolith

Think of any MVC pattern-based API codebase, where all your controllers and POJOs (Plain Old Java Objects) or POCOs (Plain Old C# Objects) were developed, build and deployed as a single unit, and for almost all the times a single data store was used for the enterprise. I.e. One database is housing all the tables for various responsibilities, for example, Customer, Payment, Order, Inventory, Shipping, Billing, etc. as shown in the logical architecture diagram below. I.e. all the various responsibilities are together.

Monolith architecture

  Monolith Pros:

• Less Crosscutting Concerns: Being monolith and having all the responsibilities together, single or few implementations can cover all the major cross-cutting concerns such as security, logging.

• Less Operational Overhead: Having one large monolith application means there’s only one application you need to set up logging, monitoring, testing for. It’s also generally less complex to deploy, scale, secure and operationalize.

• Performance: There can also be performance advantages since shared-memory access is faster than inter-process communication (IPC).

Monolith Cons:

• Tightly Coupled: Monolithic app services tend to get tightly coupled and entangled as the application evolves, making it difficult to isolate services for purposes such as independent scaling or code maintainability.

• Harder to Understand: Due to many dependencies, monolithic architecture easily become harder to understand.

• Deploy all or none: When a new change needs to be pushed, all the services need to be deployed. I.e. if something changed in OrderController and you want to proceed with deployment, all other controllers and code will be deployed unwantedly.

• Scale all or none: Scale-up or Scale-out, it’s for entire functionality.

Microservice

Gartner defines a “Microservice as a small autonomoustightly scopedloosely coupledstrongly encapsulatedindependently deployable, and independently scalable application component. “ Microservice has a key role to play in distributed system architecture, and it has brought a fresh perspective.

Unlike monolith, a microservice strictly follows the Single Responsibility Principle (SRP) due to being tightly scoped around the business capability/domain for example Payment. Think of an MVC pattern-based API codebase where a controller and POJOs (Plain Old Java Objects) or POCOs (Plain Old C# Objects) were developed, build and deployed for just one single responsibility i.e. business capability. This microservice architecture will then lead to having many such projects and each business capability having its own database.

No alt text provided for this image

Microservice Pros:

  • Easier Deployments: Monolith was deploying all or none. Microservice is a small service, the dev team has complete control on what needs to be deployed and leave another feature’s code untouched. I.e. if changes made in Payment service, only payment can be deployed. This was not possible with a monolith.
  • Scalability: Being a small tightly scoped service design, it gives freedom and flexibility to scale whichever service you want. For example, if needed only Payment can be scaled up/down/out.
  • Easier maintainability: Each microservice service is autonomous and so being small service it’s much easier to maintain than a monolith.
  • Problem isolation: Each service has its own codebase and deployed in its own space. Hence, any problem with self or other services remains completely isolated.
  • Single Responsibility: Single Responsibility Principle is at the core of microservice design. This drives all other goodness microservice architecture offers.
  • Separation of Concern: Microservices architecture leads towards building tightly scoped services with distinct features having zero overlaps with other functions. 
  • Deep domain knowledge: Microservice encourages the product mindset and leads towards establishing deep domain knowledge with “you build it, you run it” mantra.

Microservice Cons:

  • Cultural Changes: It requires a cultural shift and organizational alignment to adapt microservice architecture, and the organization will require a mature agile and DevOps culture. With a microservices-based application, the service team needs to be enabled to manage the entire lifecycle of a service. Read my article on STOSA (Single Team Owned Service Architecture)
  • More Expensive: Microservice architecture leads to growing costs, as there are multiple services. Services will need to communicate with each other, resulting in a lot of remote calls. These remote calls result in higher costs associated with network latency and processing than with traditional monolith architecture.
  • Complexity: Microservices architecture by nature has increased complexity over a monolith architecture. The complexity of a microservices-based application is directly correlated with the number of services involved, and a number of databases.
  • Less Productivity: Microservice architecture is complex. Increased complexity impacts productivity and it starts falling. The Microservice development team usually requires more time to collaborate, test, deploy and operationalize the service which certainly requires more time.

Summary

Microservice and monolith architecture, both have their pros and cons. Microservice architecture is not a silver bullet, but teams that aspire to be digitally transformed and writing services with a product mindset, microservice architecture is certainly worth consideration. 

Seattle Code Camp 2018

September 19th, 2018 | Posted by Vidya Vrat in Architecture | Community - (0 Comments)

This was 3rd years in a row, and on Saturday, September 15 I gave two sessions at Seattle Code Camp 2018

Session slides are available at my GitHub 

The first session was on “How to become a Software Architect”. Many aspirants and practicing architects attended my session and asked various questions on architect career path.

The second session was on “Microservices: what, why and how?”. This session also went very well, and I ran out of time to address all the questions related to many individual’s architecture designs and how to solve a problem they are facing. Hence, few topics were discussed after the session in the lobby.

What some of the participants said

I look forward to Seattle Code Camp 2019.