Table of Contents
It is usually in the planning stages after figuring out what your Application will do, what technologies it will be built upon and how many iterations it needs, you come to the question of what development processes should we adopt for it.
Well, no one is as primitive as to follow the Waterfall model today (so is my presumption) unless your organization is rigid to change and intends to utilize antiquely setup change process infrastructure. Most organizations would like to migrate to modern models of development which are in the news. Cloud Native is one such buzz word, which echoes today frequently.
It is observed as an evolutionary trend to gradually move all your services and infrastructure to the Cloud. But would that suffice to categorize your Application as Cloud Native? And is Cloud Native the property of an application or is it a development methodology or something beyond that?
If you are in a crisis where your services are partially on the cloud and partially on rented/owned platforms; riddled about which development model to be used in such a scenario, here we would briefly run through what Cloud Native is and how .NET Core and Azure DevOps will help you achieve it.
What is Cloud Native?
Cloud is no longer just a place to rent your infrastructure or platforms from. A decade into the wide-spread of Cloud services, the application of the Cloud has expanded remarkably. We have come up with alternatives of how to best utilize the Cloud platform, not just for hosting, but also for blending all services required for creating, maintaining and scaling an application for an organization.
If you have an application hosted on the Cloud and you are deploying your modules to the Cloud directly, chances are that you are already using a few of these services that constitute being Cloud Native.
To give you a clear picture, Cloud Native is neither restricted to a Cloud or an Application hosted on it. Rather Cloud Native is an approach of how you design, build and deploy your applications optimally utilizing all the development mechanisms provisioned by Cloud Computing.
“The move from mainframes to PCs completely changed the way we think about building applications. Client/server changed it again. Mobile, again. The move to containers and Cloud Native apps is on the same scale.” Greg DeMichillie, Google
The whole idea behind being Cloud Native is to deliver faster, accurate services to your clients on a timely basis.
Microsoft has come up with multiple utilities to make this possible. Azure DevOps and Container driven delivery in .NET Core is a perfect blend to deliver Cloud Native applications. .NET Core brings to the table containerized delivery and microservices. While Azure DevOps provides you with a combination of all utilities hosted on the Cloud that will help streamline and expedite delivery.
But let’s not rush ahead.
Let us go through what utilities a cloud platform can provide that will make our development process easier and faster.
What is DevOps?
Since its inception, DevOps has vastly spread in the Technology industry, with CTO’s intending to change their “IT Culture” into “DevOps Culture”.
DevOps is a cultural change, which promotes improved collaboration between the Development and Operations teams, to facilitate better coordination, ownership and faster delivery.
CI/CD
Continuous Integration and Continuous Delivery are an integrated part of DevOps, which facilitates a natural collaboration between the Development and Operations teams.
Continuous Integration is developed with the need for development teams to constantly integrate their code and test its accuracy. This requires driving a build and testing at the request.
Continuous Delivery, on the other hand, serves the need for rapidly deploying releasable code batches to the production, at a market-accepted pace. The intention of the CD is not to cause a complete downtime of the functioning system.
This demands the utilization of improved technology and automation tools to sustain a seamless delivery workflow and minimize manual intervention.
Azure DevOps is one such comprehensive solution facilitated by Microsoft that provisions you with all services to exercise your DevOps capabilities. Azure DevOps works with any type of application, regardless of the framework, platform, or Cloud. Which means your application need not be hosted on the Azure Cloud to utilize Azure DevOps.
Azure DevOps provides all services required in the development lifecycle, like Azure Boards for agile planning and tracking, Azure Pipeline for CI/CD across platforms and languages, Azure Test Plans for automated testing and Azure Artifacts for hosting and sharing packages with your teams. Further, they provide access to multiple extensions to collaborate with external applications like Slack, Docker, TimeTracker, GitHub and 1000 other apps.
The most lucrative reason for Development teams in choosing Azure DevOps for their Cloud Native applications is the idea of building software Serverless. While building software on with Azure DevOps you do not need to care about managing infrastructure. The scaling, availability, and performance of the platform are completely handled by the Azure platform for you. Azure handles the scaling, availability and performance of the platform for you.
What is Containerization?
The common route that most application development architectures take starts from Development, to Quality, and finally, Production. Development is where the developers work on their respective modules and perform unit testing. The Testing team comes into play on the Quality Server where they perform thorough testing of the modules delivered, and finally, after End user testing, the code is deployed into Production.
But the problem faced is that all these platforms are seldom in sync with each other. Most of the times the configuration on which the development server operates, is entirely different from that of the Production, hence causing clashes when the same code travels to production.
Gradually the concept of Virtual Machines came into play where the underlying platform imitates dedicated hardware for the application. The Virtual Machine acts as an abstraction of the underlying hardware and simulates a physical machine. When multiple VMs run on one server, each VM carries its own copy of the Operating System on which our applications are hosted. But this required creation of individual Virtual Machines for each application that is deployed.
An alternative to this is Containerization, in which the entire application is encapsulated in a container with its own operating environment. Hence overcoming the hurdles of development and deployment in isolated environments. In this case, the containers provide the abstraction of the application layer i.e. the OS.
The most popularly used Containerization platforms are Docker and Kubernetes.
These platforms work by packaging the entire application code and its dependencies required to smoothly run the application, into a Container. This Container can then be moved to any platform irrespective of the underlying hardware or software where the Containerization Engine is available. Hence an application created in Kubernetes can be moved across any other platform that hosts Kubernetes keeping the consistency of the application intact.
Microsoft promotes both the .NET and .NET core frameworks which can be used for developing Cloud Native apps. If you are puzzled about whether to choose the .NET Framework or .NET Core for your containerized applications, do go through the below .NET architecture e-book which would be a perfect guide for you.
Choosing Between .NET Core and .NET Framework for Docker Containers
To summarize it says – If your application has cross-platform needs, if it is based on microservices (explained in the next section), and if you need to build lightweight containers and load them faster; you need to opt for .NET Core.
On the other hand, if your existing application has strong dependencies on the Windows platform or requires third-party libraries, which are not supported by .NET Core, you need to go for the .NET Framework.
Here is a quick read, if you are discussing migrating from .NET Framework to .NET Core.
What are Microservices?
Previously the standard process of development was using the Monolithic Architecture. In the Monolithic Architecture, the entire application is distributed into components. Once all the components are developed the entire application is deployed as a single packaged unit. The monolithic process is simple to follow hence easy to develop and deploy. But as the size of the software starts to grow the maintenance takes a hit.
Making a minor change to any of the functionalities or appending new services needs the entire application to be repackaged and redeployed hence turning into a tedious process in case of continuous deployment.
A potential problem in the smallest of the functionalities of a component will require downtime for the entire application. Scaling monolithic applications across platforms also become a big problem.
As the name suggests, the microservices architecture structures an application as a collection of services. This architecture is business-oriented, wherein each service encapsulates core business functionality. These services are loosely coupled to reduce dependency on one another. They can be independently deployed and tested. And as these services are organized around business processes, each service can individually be handled by a small team. Microservices are supposed to be small and concentrated on specific areas of concern, making them faster to load and easier to scale.
Since the application is segregated into a group of services, DevOps can concentrate on deploying each service individually rather than repackaging the entire application, as in the case of the Monolithic Architecture. This provides the potential to increase the number of iterations in which the software is developed. Isolation of services also isolates the debugging of certain functionalities without hampering the rest. This, in turn, increases the Efficiency and induces Agility in the software development process.
Even though you can create Containerized applications that do not follow the Microservices architecture and vice-versa, they are often used together. Microsoft markets .NET Core as the best option if you are using Containers and Microservices together for your app development. Unlike the primitive .NET framework, .NET core is used for cross-platform applications. The containers developed using .NET Core are lightweight, making it faster to deploy and start.
Further .NET Core facilitates you to work in junction with microservices developed on other parallel platforms, which gives it a significant edge over others.
If you are considering independently working with Microservices, here are a few technologies that you would like to look at for building your Microservices.
Why Cloud Native?
The idea behind moving to the Cloud native architecture is to deliver more value at a faster rate to the client. Hence, Cloud Native is a combination of Agile, CI/CD, Microservices, Automation, Flexibility, and this list will keep evolving as additional capabilities are added to the cloud. The Cloud native approach can add numerous positives to your business:
Modularity
The application development process is simplified. As we distribute our software into microservices, the dependency is decreased, and each module can be developed independently.
Scalability
Applications, which are developed in the Cloud Native fashion are highly scalable as they can be easily modified in real-time to accommodate an environment without radically affecting other services or without causing complete application downtime.
Monitoring
As each of the microservices relates to Business functionality, monitoring Business processes is easier. You can segregate which module to concentrate on, to target the improvement of the functionality or the performance of a service.
Deployability
Since we have adopted the CI/CD over a Cloud infrastructure, batches of code can be deployed from any location at any time. This promotes rapid deployment and iterative improvement of the product services. Hence, improvement of all services occurs in parallel.
Replaceability
As our services evolve rapidly to accommodate changed functionalities, the microservices architecture keeps doors open to entirely replace the service with a design or architectural change.
Resiliency
With microservices, the functionalities are dispersed across multiple services. This prevents a single point of failure for the entire application, hence permitting it to perform better. Further, the disaster recovery is limited to certain functionalities, which are affected.
Overall adapting the Cloud Native approach is not as elegant as changing the development methodology of your product. Multiple new approaches are introduced into your working culture with Cloud Native, such as continuous delivery, initiating with an MVP, rapid iteration and adapting to the DevOps culture. The major transition is moving your existing delivery model to the Cloud. Introducing these cultural changes through your organization may be a major challenge you face while transitioning. This needs to be done in stages and a gradual pace that your workforce can adapt to.
The recommendation would be to consult both a DevOps expert and a Cloud Migration expert before moving ahead.
