What is the meaning of Cloud Native?
Cloud-native refers to the way an application is built and deployed, specifically leveraging the benefits of the cloud, rather than where it lives. It implies that the apps exist in the public cloud, rather than within an on-premises datacenter.
Traditional development focuses on the application 1st and where the infrastructure is hosted 2nd. Cloud native development is the notion that we consider all factors from day one, and where the application is hosted and what sort of services or technologies can be leveraged from that platform.
What is cloud native DevOps?
DevOps is a popular approach to software delivery used to build, test, deploy, and monitor cloud native applications with speed, quality, and control. Born from the Agile methodology, DevOps brings Development and Operations teams together. By focusing on eliminating silos, this approach decreases time needed to address bottlenecks to enabling continuous software delivery.
What’s the difference between traditional development & cloud native development?
Traditional development focuses on the application first and where the infrastructure is hosted second. Cloud native development is as much a philosophy as it is a set of tools. It’s the notion that we consider all factors from day one. Through cloud native development we consider where the application is hosted and what sort of services or technologies can be leveraged from that platform.
What’s the impact of cloud native development?
Infrastructure as a service (IaaS) has revolutionized development. Amazon Web Services (AWS) has given us the opportunity to use infrastructure that is not self-managed. Knowing that we will host on AWS opens a lot of opportunities that wouldn’t be available if we left hosting until the end. With AWS we’re able to integrate technologies that cannot be integrated after the fact. We’re also able to focus on application logic, which is our key differentiator from competitors, instead of worrying about things like OS management, software patches, durability concerns, and availability concerns. With AWS, these concerns are no longer top of a developer’s mind. Cloud native technology doesn’t cost unless someone is utilizing services. You won’t pay for compute or bandwidth unless someone hits your website. This changes the development cycle.
Developers are used to developing applications locally and testing them locally, then deploying into the cloud near the end of the project, or when QA is ready to do some testing. When you’re doing cloud native, you need to deploy day one. That means developing processes, tooling, and other things to help gain productivity and make sure your developers aren’t stuck waiting for deployments, resources, or DevOps folks to help them out.
How can you take full advantage of cloud native development?
Onica helped Alistar Group build a serverless application on AWS. This application helps them manage their fleet of hundreds of trucks and drivers as they deliver cargo to their customers across East Africa. Before, they were utilizing spreadsheets which didn’t scale with their rapid growth. The introduction of this application streamlined their operations process dramatically.
First, we worked with their team to develop the business use case for building a custom application. Then, rather than starting with a web server to host the application, we started with Amazon API Gateway and hosted a
REST API. We built the user interface using Angular II technology to achieve a streamlined and responsive web experience. On the backend, we utilized AWS Lambda to host all of the application logic and Amazon DynamoDB to store data at persistent state. In addition, we introduced Amazon ElasticSearch to help with full text search capabilities, as well as analyzing time series data that they collect from their fleet of trucks.
This development model worked well for them because it kept costs low as they scaled up, but allowed them flexibility to scale down when they needed to without having to re-architect later because their scalable cloud architecture was there from day one to support any workload they might throw at it.