One of the current trends in software development is called "cloud-native". Many times, some new technology or approach to development comes along and is quickly replaced. Some might believe that is the case for "cloud-native"; however, for now, cloud-native is changing the way software is developed, deployed, and maintained.
I've experienced the term cloud-native using in meetings and presentations where the speaker was not fully aware of it's full technical architecture nor its best use cases, it was mentioned in the context of a buzz-word gaining popularity.
Cloud-native has now evolved into much more. It is now gaining a strong following and its own foundation (Cloud Native Computing Foundation).
So, what is “cloud-native”?
“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...”
Source: Cloud Native Foundation
A composition of related microservices (small, single function applications working together to form a larger system), written in a wide variety of languages, can be containerized using a tool such as Docker, and deployment can be orchestrated with a tool such as Kubernetes or Amazon ECS. This deployment might even be in the collaboration with an integration platform such as MuleSoft using their Anypoint Platform and Fabric product.
The container allows for environment independence and horizontal scaling as primary attributes, while orchestration takes care of the following chores:
Benefits of Cloud-Native Architecture
The cloud-native approach allows for
Microservices are single function applications that have a well-defined bounded context and its functionality exposed as an API. To create complete systems, multiple microservices are integrated with one another into a network of applications.
Each node of the network (a single microservice) can be easily updated, maintained without affecting any of the other nodes. This network of applications can also interact with legacy systems, SaaS and PaaS based services even if they are deployed to other clouds or on-premise.
Challenges of Microservices
The first challenge of creating microservices is sizing. It is critical that the user story that defines the single function it's to perform is complete and detailed enough so that the developer understand precisely what the services is limited to doing.
By doing the API first approach, an API can be designed and along with the user story, the developer should be able to code the service in the most complete and efficient manner.
Dependency management is another critical aspect. Microservices should not share dependencies, but if they do, those dependencies need to be very accessible in a reliable manner.
Because a collection of microservices are now deployed as a more complex distributed system, not only is dependencies important concerns, so is the ability to monitor and account for proper resource allocation for each dependency.
Consider API management tools such as Uptrend, Amazon CloudWatch (for AWS), or API Fortress.
Microservices can be written in many different languages with or without a framework. Frameworks such as Spring Boot, which incorporates the Spring Framework and other libraries; Seneca or IBM supported Loopback for Node.js; or Go Micro for the GO language are some examples.
Cloud-native computing provides a better approach to implement complex systems that need to scale quickly and operate efficiently.
By using containers, orchestration you can more easily schedule, test, deploy, and maintain a network of applications in multiple environments built on a microservice-based architecture.
A micro-service architecture provides benefits related to better encapsulation, modularity, ease of testing and maintaining; however, they also present some additional challenges due to a more complex distributed structure.
I've worked for over 30 years in financial services, software development, and as an entrepreneur. Additionally, as a longtime whitewater kayaker and rock climber, I believe I have married both business and risk taking lessons together deriving some insights into life and work's pitfalls and opportunities.