DEV Community: Dhruvesh Patel

DJL - Deep Java Library

Dhruvesh Patel — Sat, 24 Oct 2020 03:41:41 +0000

Want to get hands dirty with Machine Learning / Deep Learning, but have got Java background and do not know where to start? Then read on, this post is about using existing Java skillset and ramp-up your journey to start building deep learning models.

What is DJL?

DJL is an open source library to build and deploy deep learning in Java. DJL is built by AWS and is open source.

DJL provides a native Java development experience and functions like any other regular Java library & expedite machine learning and deep learning journey. Developers can use their existing IDE (Eclipse/ IntelliJ) to build, train and deploy models and DJL makes it easy to integrate this models with Java Apps.

The simple APIs abstract away the complexity involved in developing Deep learning models. With the bundled set of pre-trained models from ModelZoo, users can immediately start integrating Deep learning into their Java applications.

DJL is engine-agnostic and goes with Java fundamental "Write once, run anywhere". Developer can develop model using DJL and run it on an engine of your choice - MXNet, Pytorch, TensorFlow.

DJL Example for Object Detection

Object detection is a computer vision technique for locating instances of objects in images or videos.

In this example, we will learn how to implement inference code with a ModelZoo model to detect dogs in an image. Source code for this model is available here.

Local software setup

Install JDK 8 (DJL has some known issues with JDK 11)
Install IntelliJ a IDE
Import DJL project using IntelliJ

Refer setup related more details here.

For Java source code for ObjectDetection.java class, which is using DJL can be found here.

Run the Object Detection Example:

Input image is used as below.

Build the project and run Use the following command to run the project:

Output should look like the following:

An output image with bounding box will be saved as build/output/detected-dog_bike_car.png:

Conclusion

Within Deep learning landscape, there are lots of resources for Python users like NumPy for data analysis or frameworks such as MXNet, TensorFlow. But, the very few sources for Java. Thanks to AWS team, DJL provides open source tools to train and serve Deep learning models in Java and makes it easy to start deep learning journey.

Enjoy building machine learning applications with power of DJL !

Please like, share and comment your views/ opinion.

Disclaimer - This post is my personal opinion and does not reflect those of any of my past, present or future employers or affiliations.

Software Architecture - Five Common Design Principles

Dhruvesh Patel — Sat, 24 Oct 2020 03:21:52 +0000

This post will talk about popular design principles - used in Software architecture world, which are time-tested and even relevant today.

What is Software Architecture?

Software Architecture is the shared understanding that the expert developers have of the system design.

In other words described by Ralph Johnson & Martin Fowler, Architecture is about the decisions you wish you could get right early in a product or project lifecycle. Architecture is about the important stuff, whatever that is.

To draw an analogy with tree for ease of understanding, Architectural investment builds new and stronger branches. Features put leaves on branches.

Software with well-defined architecture leads to good quality software and that leads to high velocity over time. Considering trade-off between quality and cost, the high quality wins, always. Over time, Architectural investment pays off with ease of developing new features in short time.

Common Architectural Principles

SOLID Principles

S - Single-responsibility principle - A class should only have a single responsibility, that is, only changes to one part of the software's specification should be able to affect the specification of the class.

O - Open–closed principle - Software entities ... should be open for extension, but closed for modification.

L - Liskov substitution principle - Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program. Design by Contract.

I - Interface segregation principle - Many client-specific interfaces are better than one general-purpose interface.

D - Dependency inversion principle - One should "depend upon abstractions, [not] concretions.

KISS (Keep it simple)
Everything should be made as simple as possible. As Simple as this, nothing complicate, Design systems to be simple and easy to understand and maintain.
YAGNI (You aren’t gonna need it)
Do not build it until it is needed. There are lots of envisioned features, which are not needed on priority, leave them aside. At the same time, having view of what is coming will actually set the right direction of solution.
Opportunity Cost Principle

Opportunity costs define what we have to give up in getting that value. For the highest value, we should always opt for the option that offers maximum benefits at the lowest cost.

Always weigh down different options against one another. Choose a path that adds maximum value to the project.

Don't repeat yourself (DRY)

Avoid specifying behavior related to a particular concept in multiple places within application. As this will lead to a frequent source of errors. At some point, a change in requirements will require changing this behavior. It's likely that at least one instance of the behavior will fail to be updated, and the system will behave inconsistently.

Rather than duplicating logic, encapsulate it in a programming construct. Make this construct the single authority over this behavior, and have any other part of the application that requires this behavior use the new construct.

Conclusion

Common design principles mentioned above are guiding light in software architecture and provides very good reference point. But there will always be exception cases where this principles may not be applicable in its pure form, So always refer context in which software is being built and then accordingly choose suitable version of software architecture principles. There are just a few common set of time-tested software architecture principles, list can go on and on with cloud and other modern technologies.

Enjoy architecting software systems and make them secure, reliable, highly efficient and cost effective.

Please like, share and comment your views/ opinion.

Disclaimer - This post is my personal opinion and does not reflect those of any of my past, present or future employers or affiliations.

How to deploy Spring Boot app to Azure App Service?

Dhruvesh Patel — Sat, 24 Oct 2020 02:52:30 +0000

If you are building Java based spring boot app, but struggling to deploy app to Azure Cloud? This blog post is for you, It will provide brief introduction of Azure App Service and App service Plans and the step-by-step guide to deploy Java based Spring boot app to Azure App service.

What is Azure App Service?

Azure App Service is a Platform as a Service offering from Microsoft Azure Cloud, which allows developer to focus on developing new business features and not worrying about running and managing the underlying infrastructure. Azure Service Fabric provides the underlying magic for App Service including all good things that comes with cloud - scaling, availability and redundancy.

Benefit of using Azure App Service :

Faster time to market to compete in modern digital transformation powered innovation and disruption
Deployment slots are live apps with their own host names. App content and configurations elements can be swapped between two deployment slots, including the production slot. Allows to test deployment in staging before moving to production and then swap staging to be production without additional cost
Security is integrated within App Service - offers layered security like Multi-factor authentication (MFA) and other security features like authentication.

App Service Plans:

An App Service Plan is like a container in which your web applications run. it is used to determine the computing resources (CPU, RAM, Cache, disk space, etc.) available to your application.

Following image shows comparison of various App service Plans such as Free/Shared, Basis, Standard, Premium and Isolated & their pricing.

Maven Plug-in for Azure App Service:

The Maven Plugin for Azure App Service helps Java developers to deploy Maven projects to Azure App Service.

Pre-requisites before using this maven plug-in,

Install Azure CLI ( Refer this link )
Sign in to Azure Portal using below command.

Deploy Spring Boot app (Java based) to Azure App service:

Once above Pre-requisite steps are completed,

Using IDE (Eclipse/ IntelliJ) for Spring boot maven project, add azure maven plug-in in pom.xml file.

Typical configuration for Azure Maven plug-in for Java based spring boot app is as below (You can select an existing Azure Web App or create a new one on prompt. Below snippet is for using existing App service Plan and App Service).

Deploy your Java app to Azure using the following command

Finally, Navigate to Azure Portal -> Resource Group -> App Service which was used to deploy Java application and verify the App is running.

Conclusion

Azure App Service provides fully managed platform for building, deploying and scaling your web apps - Platform-as-a-Service. It greatly speeds up deployment of Spring boot based Java application to Azure App Service.

Happy coding !

Please like, share and comment your views/ opinion.

Disclaimer - This post is my personal opinion and does not reflect those of any of my past, present or future employers or affiliations.

Apache Kafka - Fundamentals, Use cases and Trade-Offs

Dhruvesh Patel — Sat, 24 Oct 2020 02:36:42 +0000

This post will focus on open source and popular Apache kafka platform related brief fundamentals, Use Cases and Trade-offs with other popular messaging technologies.

Kafka Fundamentals - Brief

Apache kafka is an event streaming platform. It provides distributed, high-throughput, low-latency, fault-tolerant platform for handling real-time data feeds - known as events.

It can be used in different ways due to various capabilities combined in Kafka.

Message System - to Publish and Subscribe events
Stream Processing System - to Process steams of events
Storage System - to Store log of events reliably (forever, if needed)

Kafka has topics, partitions, producers and consumers, which are basics for any messaging system. For more details on Kafka 101, please refer this link, where it is very nicely explained.

Kafka has following message / event delivery guarantees between producer and consumer.

At most once — Messages may be lost but are never redelivered.
At least once — Messages are never lost but may be redelivered.
Exactly once — Each message is delivered once and only once.

Kafka Use Cases

For anything that deals with events and real-time data, Kafka is the way to go to process events and get insights - all in real-time. Kafka supports wide variety of use cases due to large ecosystem. Some of the example use cases are as below.

Financial Services - Real-time fraud detection and faster payments
Automobile - Real-time data cluster for Anomaly detection, Alerts and Personalization for better driving experience
Healthcare - Real-time health sensors data to get better insights to serve patients and save lives

Kakfa can be used as backbone to integrate various systems - be it data analytics use case or microservices communications in an event-driven architecture. Following diagram shows kafka as backbone for various systems integration.

Kafka Trade-offs with other messaging systems

For basic, single machine, message oriented, point-to-point systems communication, classical messaging suits with RabbitMQ or ActiveMQ.

But for any event-streaming, where there is event-based communication with multiple consumers and need ordered events (either same events to multiple consumers or specific events to specific consumer group), then Kafka is best suited.

Apart from being messaging system, Kafka can be leveraged as stream Processing System (to Process steams of events) and Storage System (to Store log of events reliably - forever, if needed). It also has lots of other features in Kafka ecosystem, such as kafka connectors and kafka streams (please refer kafka documentation for more details). So for event-driven, real-time systems - Kafka is most matured and complete ecosystem.

Enjoy building event-driven systems with Kafka !

Please like, share and comment your views/ opinion.

Disclaimer - This post is my personal opinion and does not reflect those of any of my past, present or future employers or affiliations.

AWS Well-Architected Framework - Best Practices to design systems in Cloud

Dhruvesh Patel — Fri, 23 Oct 2020 16:51:15 +0000

This post will talk about my key take-aways after reading and practicing AWS well-architected framework and five pillars that define how well the system architecture is?

AWS Well-Architected Framework

It defines set-of guidelines and design principles to follow while building systems in the cloud. It is a must read guide on architectural best practices and trade-offs to consider, while designing and operating reliable, secure, efficient and cost-effective systems in cloud.

AWS Well-architected framework is based on 5-pillars as listed below.

Security
Reliability
Performance Efficiency
Cost optimization
Operational Excellence

Security

Security is the most important aspect of cloud-native solutions. Prevent, Detect, Respond and Remediate security aspects to implement optimum security posture for Organization and as a thumb rule, Apply security at all layers.

Following are high level design principles for achieving security.

Prevent - Define IAM policy based on Principle of Least privilege (AWS IAM, SSO, MFA), Ensure Data Protection using encryption - In transit & At Rest (AWS KMS, CloudHSM, SSE)
Detect - Logging and Monitoring of services (AWS CloudTrail, AWS CloudWatch, AWS GuardDuty)
Respond - Automated incident response and recovery (AWS Config + Lamdba, AWS Systems manager & Automation Playbooks)
Remediate - Leverage event-driven automation to remediate, where possible and secure cloud environment (AWS Security hub and Manual intervention)

Reliability

Achieving reliability can be challenging in traditional on-premises environments due to single points of failure, lack of automation, and lack of elasticity.

In Cloud, Architect and design solutions with mindset of "Everything fails all time".

Following are high level design principles for achieving reliability.

Automatically recover from failure - Monitor workload using KPIs, Trigger automated recovery process when threshold is breached. Aim to be able to Anticipate and Remediate failure before they occur.
Test Recovery Procedures, Scale horizontally to avoid single point of failure (where suitable), detect failures and auto-heal itself
Deploy using Immutable infrastructure

Performance Efficiency

Adopt data-driven approach to build high-performance architecture. Depending on use case, trade consistency, durability and space for latency to deliver higher performance. Cloud enables to embrace evolving architecture depending on data insights and usage patterns.

Following are high level design principles for achieving operational excellence.

Experiment often
Have performance metrics in place
Focus on going global as you evolve
Use serverless architectures

Cost optimization

Cost optimization is a continual process of refinement and improvement over the span of a cloud resource. On top of having cloud budget, resource tagging and forecasts,

Following are high level design principles for achieving cost optimization.

Create cost-aware processes and culture
Purchase reserved instances and go with upfront payment where utilization is predictable
Delete unattached EBS volumes & obsolete snapshots, release unwanted elastic IPs and choose appropriate storage tiers

Operational Excellence

The operational excellence pillar includes how organization supports business objectives by running software systems efficiently and by gaining insight into operations, and then by continuously improving to deliver business value.

Following are high level design principles for achieving operational excellence.

Perform operations as code
Make frequent, small, reversible changes
Refine operations procedures frequently
Anticipate failure
Learn from all operational failures

AWS Well-Architected Tool

The AWS Well-Architected Tool helps to review the state of application and compares them to the latest AWS architectural best practices. The tool is based on the AWS Well Architecture Framework developed to help cloud architects build secure, high performant, resilient, and efficient application infrastructure.

This Framework provides a consistent approach for customers to evaluate architectures and provides guidance to help implement designs that scale with application needs over time.

Benefits of AWS Well-Architected Tool

Get Free architectural guidance
Gives access to best practices used by AWS Architects whenever you need it. Just answer series of question on your application and tool delivers step-by-step guidance on how to improve current design and architecture.
Review your application consistently
Offers single tool and consistent process to review cloud architectures across organizations. Provides potential next steps for improvement, drive architectural decision and brings architectural considerations into corporate governance.
Identify and Implement improvements
Use this tool to support continuous improvements throughout lifecycle of application. Makes easy to save point in time snapshot and track changes. If you want to start all over again, just launch one more review process to ensure your architecture continues to improve over time

Well-architected Labs provides nice hands-on labs to try out these architectural best practices.

Enjoy architecting systems in cloud and build efficient systems.

Please like, share and comment your views/ opinion.

Disclaimer - This post is my personal opinion and does not reflect those of any of my past, present or future employers or affiliations.

DevOps and CI/ CD - Faster time to market

Dhruvesh Patel — Wed, 21 Oct 2020 22:58:36 +0000

This post will talk about DevOps and Continuous Integration / Continuous Delivery to bring new products and services faster to market.

What is DevOps?

DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality.

DevOps is intended to be cross-functional mode of working, which uses wide variety of toolset that fits into one of the below category.

Coding – code development and review, source code management tools, code merging.
Building – continuous integration tools, build status.
Testing – continuous testing tools that provide quick and timely feedback on business risks.
Packaging – artifact repository, application pre-deployment staging.
Releasing – change management, release approvals, release automation.
Configuring – infrastructure configuration and management, infrastructure as code tools.
Monitoring – applications performance monitoring, end-user experience.

As we have seen in cloud-native series, cloud-native systems embrace microservices, containers, and modern system design to achieve speed and agility. But that's part of the story. How do we provision cloud environment? How do we rapidly deploy new features and updates? That's where DevOps Automation comes into picture - Infrastructure Automation and Deployment automation.

Infrastructure Automation

This is popularly known as Infrastructure as Code (IaC), it enables to declaratively script and provision the required cloud infrastructure.

The cloud resources are parameterized and dynamic, version-controlled as an artifact with code. The parameters can change across environments such as dev, qa, staging and prod. But it allows to have consistent and repeatable infrastructure across environments.

Terraform, Azure ARM and AWS Cloudformation are such IaC tools, and terraform is widely used.

Following image has some basic terraform commands.

Deployment Automation

12-factor app principles discussed earlier in first part of this blog series mentions about principle 5 - Each release must enforce a strict separation across the build, release and run stages. Each should be tagged with a unique ID and support the ability to roll back.

Modern CI/ CD Pipelines allow to fulfill this principle.

Following diagram shows typical flow for setting up CI/ CD pipelines.

CI - Continuous Integration part is where the code push triggers a build stage that transforms the code into a binary artifact.
CD - Continuous Deployment part is where the release stage picks up the binary artifact, applies external application and environment configuration information, and produces an immutable release. The release is then deployed to a specified environment.

And finally, the released feature is run in the target execution environment. Releases are immutable meaning that any change must create a new release.

Azure DevOps is one-stop solution for all DevOps and agile needs for embracing automation. All other public cloud providers offer parallel tools for DevOps and CI/ CD.

Following image shows CI/ CD pipelines flow using Azure DevOps.

DevOps Culture Adoption

By adopting DevOps culture in organizations and using automation mentioned above, Organizations have achieved significantly faster time to market. Moved from one in a quarter release to on-demand updates or at least per week / per sprint release cycle. The goal is to release frequently, gather feedback and fail-fast early in the development cycle, when it is less expensive to improvise / fix. CI/ CD practices allows better collaboration across teams and software quality, as it automates mundane, repeated tasks. DevOps adoption is key for achieving high performance across organization as it lets teams focus efforts on building important business features and bring growth.

I hope you enjoyed reading this cloud-native series and learnt something new. Cloud-native application empowers digital disruption to brings better products and services to market - with quality and speed.

Happy journey to cloud-native adoption and transformation !

Please like, share and comment your views/ opinion.

Disclaimer - This post is my personal opinion and does not reflect those of any of my past, present or future employers or affiliations.

Containers - Docker, Kubernetes and Cloud Buildpacks

Dhruvesh Patel — Wed, 21 Oct 2020 19:38:32 +0000

This post will focus on how to create containers using open source tools and technology - starting from Docker (tool designed to build, package, deploy, and run applications by using containers), Kubernetes (Container Orchestration tool) and Cloud-native Buildpacks (quickest way to turn app code into images that can run on any cloud).

Containers

Container is used to package and run an application on a shared Operating System. They are isolated from other Containers and share the resources of the underlying Operating System, allowing for efficient restart, scale-up or scale-out of applications across clouds. Containers typically contain Microservices.

Benefits of using Containers over traditional Virtual Machines such as,

Agility - Accelerate software development / deployment & Fast application start-up, as no OS to boot like VMs
Portability - Easy moving across environments as standardized packaging for software and its dependencies
Security - Built-in security capabilities
Cost Savings - Lightweight and consumes less computing resources (CPU, RAM, disk space)

Following diagram shows differences between VM and Containers.

What is Docker?

Docker is a popular open source platform with ecosystem of products that use containers, which allows to package and run application in an isolated environment.

Docker comes with eco-system of products like,

Docker Hub - hosted repository service for finding and sharing container images
Docker Engine - an open source containerization technology for building and containerizing your applications
Docker Desktop - enables you to start containerizing in minutes and is the easiest way to run Docker Engine on personal laptop

Docker collaborates with the open source ecosystem through an array of projects that continue to fuel the containerization movement, the Docker platform and other Docker products. For more details, Refer https://www.docker.com/community/open-source

Docker commands

Sample Dockerfile for Java based Spring Boot Application:

Kubernetes

Kubernetes is a Container orchestration platform, which is portable, extensible, open-source platform for managing containerized workloads and services and facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem.

Following diagram shows different components of Kubernetes.

Kubernetes provides ready-to-use functionality for below management tasks.

To get hands dirty with deploying containerized apps to Kubernetes, start with minikube, it helps to deploy Kubernetes locally.

Cloud Buildpacks

Cloud Native Buildpacks (https://buildpacks.io/) transform your application source code into images that can run on any cloud - without any hassle of knowing low level details of defining Dockerfile.

The fastest way to try Cloud Native Buildpacks is via the pack CLI from buildpacks. It helps to create a runnable app image from source code without writing Dockerfile.

In order to run the build process in an isolated fashion, pack uses Docker. Run following commands to build sample Java application image.

That’s it! You’ve now got a runnable app image called myapp available on your local Docker daemon - in just under 100 seconds. Please note, that your app was built without needing to install a JDK, run Maven, or otherwise configure a build environment. Pack and buildpacks took care of that for you.

Happy coding and containerizing !! Please like, share and comment your views/ opinion.

Disclaimer - This post is my personal opinion and does not reflect those of any of my past, present or future employers or affiliations.

Microservices - Introduction, How to design & develop? When to use?

Dhruvesh Patel — Wed, 21 Oct 2020 12:57:29 +0000

This article will focus on microservices architecture introduction, benefits, how to design & develop and when to use for this architecture pattern.

Microservices Introduction

Microservice architectural style 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.

It has following characteristics:

Built around business capabilities
Loosely coupled services and highly resilient, scalable services
Independently deployable using automated pipelines (CI/ CD)
Capable of being developed by a small team - highly maintainable & testable

With legacy Monolithic architecture style, which is often developed as a single process, all functionality is deployed as one large process. And it scales by replicating the monolith on multiple servers. This has limitations such as difficult to selectively scale, long term commitment to technology stack and hard to modify as monolith grows over time and long time to develop new features.

Benefits of Microservices Architecture:

Evolutionary design
Possible to selectively scale up and down based on volume
Enables the continuous delivery and deployment - shorter time to market
Easy to understand and add new team members
Flexibility to choose most suitable technology stack for new business change

Following diagram by Martin Fowler summarizes comparison between monolith and microservices.

How to decompose and develop microservices?

To design system with microservices, Domain driven design (DDD) principles are very handy. It says, develop microservices by considering high cohesion of related business functionality.

DDD refers to the application’s context to solve a particular business need as the domain. A domain is consists of multiple subdomains. Each subdomain corresponds to a different part of the business.

For example, Online grocery store as domain would have following sub domains.

Product Catalog
Order Management
Delivery Management
Inventory Management

This segregation of bounded context, domains and sub domains require good understanding of business and organization structure.

Each microservice is built with single responsibility principle, but not too granular that a single business change affects multiple microservices and requires them to deployed together most of the time (sometimes for a big change, this is fine. But not always, otherwise it is just another monolith).

Another analogy that helps with microservices design is the design of Unix utilities such as grep, cat and find. Each utility does exactly one thing, often exceptionally well, and can be combined with other utilities using a shell script to perform complex tasks.

Following diagram shows illustrative views of microservices architecture.

How to develop microservices?

In order to achieve loose coupling, the system with microservices might have more than one/ database per service. So consider saga pattern for distributed transaction management as 2-phase commit is not an option. Each service can publish events as and when their data changes, and other services consume these events to take relevant action on their side (update their data). Consider Event sourcing design pattern.

For retrieving data owned by multiple services, consider Command Query responsibility segregation (CQRS) and API Composition design pattern.

It gives lots of flexibility in terms of choosing technology stack for developing microservices, but be careful to consider "hype cycle" of any technology and availability of talent pool. For example, Java is widely used and popular programming language with support of various open source framework and tools such as Spring Boot, Kafka, Swagger, to name a few. Python as well comes with lots of popular libraries such as numpy, pandas, pyTorch and talent pool.

Be careful to only choose microservices architecture when you have compelling need and demanding business case. Keep in mind that microservices architecture is not silver built that applies to all business problems and use cases.

When to use microservices architecture?

When building strategic business transformation products and services, which have long future and is likely to have high volume transactions and traffic
When existing monolithic application has known issues to accommodate scalability, agility, and delivery speed
Availability of right tools and technological expertise within team to develop cloud-native applications

Most large scale web sites including Netflix, Amazon and eBay have evolved from a monolithic architecture to a microservices architecture.

Happy coding and building microservices ! Please like, share and comment your views/ opinion.

Disclaimer - This post is my personal opinion and does not reflect those of any of my past, present or future employers or affiliations.

What is cloud-native?

Dhruvesh Patel — Tue, 20 Oct 2020 22:44:00 +0000

This post will talk about cloud-native - "what, why, how and when" cloud-native is relevant.

What is cloud-native application? The application that is built to take full advantage of the underlying cloud platform.

built in the cloud
for the cloud
maximizing the benefits of the cloud

Cloud-native computing foundation (CNCF) defines official definition of cloud-native as : Cloud-native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

Benefits of cloud native applications:

Speed - the ability to innovate, experiment and reduce time to market to bring new products and services
Safety - the ability to move rapidly but also maintain stability, availability and durability
Scale - the ability to elastically respond to changes in demand (aka scale up / scale down - without manual intervention)

Over the years, software development industry has matured and it has evolved on all areas covering - development process, application architecture, packaging, deployment and application infrastructure.

Following diagram shows evolution of software development process.

Cloud-native software development offers benefits for safety, speed and scale as mentioned in above section.

Now, that we know what and why of cloud-native, lets switch gears and understand how?

How to design and build cloud-native applications?

The widely accepted methodology for constructing cloud-native application is 12-factor application.

Following image highlights 12-factor applications methodology and beyond.

Now that we understand, why what and how of cloud-native application, lets look at when?

Application Use cases - When to consider cloud-native applications?

Strategic enterprise systems that needs to constantly evolve with business need
Apps that require shorter time to market
Apps that require components to scale individually (and not as whole)
Last but not least, team with expertise in cloud-native skillset

As a rule of thumb, Apply cost/ benefit analysis by considering cost of cloud-native development with business value of the application before jumping onto band-wagon of cloud-native application.

Conclusion

Cloud-native applications are the foundation for the modern way of software development and acts as backbone for digital transformation led growth and innovation.

Enjoy building cloud-native applications !!

Note - Cloud Native Computing Foundation (CNCF - https://www.cncf.io/), is an influential open-source consortium of over 300 major corporations. It's responsible for driving the adoption of cloud-native computing across technology and cloud stacks.

Disclaimer - This post is my personal opinion and does not reflect those of any of my past, present or future employers or affiliations.