Your applications and workloads are the foundation of your business’ ability to stay competitive, both operationally and in meeting customer experience services and product demands. Specific business outcomes will drive the type of application you need whether it be:
- Web application development
- Mobile app development
- Enterprise application development
- Ecommerce app development
- Healthcare app development
- Fintech app development,
There are many parts to successfully deploying your cloud-native application when you want to maximize them for specific business outcomes. To fully leverage the benefits of the cloud, you’ll need to consider many different tools and configuration options. To help accelerate your project, we’ve created this application deployment checklist.
Cloud-Native Application Deployment Checklist Template
1. Server Side
How Are You Serving Your Applications?
The ways in which you will use this checklist depends on how you’ll serve or deploy your application. Basically, are you serving your app from a virtualization instance, or through a Docker-based containerized application? Though both are cloud-based, they’re quite different.
Are You Scaling or Auto-Scaling?
If you’re running the application through virtualization or virtual machine (VM), you’ll require scaling. But if you’re running it from containers with an orchestration system — such as Kubernetes — you’ll get auto-scaling out-of-the-box. This can be crucial to operationalizing apps and workloads in a Kubernetes multi-cloud architecture.
What CI/CD Tools Are You Using?
This applies if you’re using a container orchestration system, such as Kubernetes.
You can use Jenkins for pure Continuous Integration (CI), and Spinnaker for pure Continuous Deployment (CD) tasks. Some will also use Jenkins for both CI/CD. You can deploy containerized applications in different ways, so your choice of CI, CD, or CI/CD will depend on your needs.
How Are You Configuring Your CPU, Memory, & Garbage Collection Settings?
If you’re using an auto-scaler, you’ll be able to estimate lower CPU, RAM, etc., requirements. In turn, you’ll save costs by not paying for surplus capacity.
In terms of Garbage Collection (GC) settings, you should test for 3-10X your app’s load — i.e., tune your GC settings based on your peak load.
2. Client-Side
Pick a JavaScript Framework
React.js is generally the preferred option for lightweight, single-page applications. Angular.js is the way forward for heavier applications. For home pages, you can use Vue.js.
Pick a Compile-to-JS Language
Though there are several compile-to-JS languages, most use TypeScript.
Pick a Compile-to-CSS Language
As with compile-to-CSS languages, though you have several options, most use SASS.
Optimize Your Assets
You should link your CSS and JavaScript (JS) files together to cut the number requests browsers need to make (i.e., save resources).Common steps include:
- Reducing your JS
- Making as many of your JS assets cacheable
- Storing assets in a Content Delivery Network (CDN)
- Cutting the number of connections you call out to and link
- Linking directly to AngularJS without downloading files
- Using a static content server for images, CSS, JS, fonts, etc., to free the dynamic web framework (e.g., Node.js, etc.) to handle dynamic requests.
3. Data Storage
Deploy Relational Databases
You have a range of relational databases to choose from, including MySQL, PostgreSQL, Oracle, SQL Server, and others. However, when selecting one, consider the following:
- Automatic failover to ensure high availability and resiliency in case of errors/crashes
- Cut workloads for maintaining uptime
Deploy NoSQL Databases
Whether you’re choosing MongoDB, Couchbase, or another solution, you should try leveraging managed cloud services. However, you should avoid trying to shoehorn databases into different platforms. For example, don’t migrate SQL datasets into MongoDB.
Deploy Queues
This requirement only applies to niche development environments, typically in BASH or trigger-based situations.
4. Configure for Resilience
Setting-Up Backups for Disaster Recovery
First, script out your infrastructure-as-code (IaC). This way, if you need to recover your application data, you can just trigger the script and stand-up your hosting infrastructure.
Second, test your back-ups as part of your release management processes. Don’t assume they just work; you’re putting yourself at risk of failure during an actual crash/disaster.
Ensuring High Availability via Multiple Availability Zones
In your application deployment plan, make sure you’re using more than one availability zone or region, especially for mission-critical applications. If one region sustains an outage, you’ll lose your application; focus on redundancy through multiple availability zones (AZ).
Application Architecture
Based on your needs, you’ll need to pick either a monolithic or cloud native microservices architecture.
Load Balancing, Auto-Scaling, Auto-Recovery
The goal behind these functions is to automate your application’s ability to identify and respond to a crash. For example, with auto-scaling, if your application needs another instance, it’ll scale-up and start a new one. And once that demand recedes, the app can close the instance on its own. Likewise, with load balancing, the application will manage container requests coming into the same port.
Graceful Degradation
If you’re deploying a microservices application, you might have a failure between several of your services. In this case, you should configure your application to handle these failures such that it doesn’t crash. To do this efficiently, you’ll need a service mesh such as the open-source Istio.
Chaos Engineering
Finally, test for resilience by running load tests against your infrastructure. You can also figure out the point at which your application will crash (e.g., its maximum load).
Using tools like Chaos Monkey to randomly shut down specific services and other parts of your deployment process lets you gauge your ability to deal with downtime.
5. CI/CD
A critical part of deploying a cloud-native application is leveraging cloud automation tools. This will require the following processes:
Pick a Version Control System
You should narrow your options to some flavor of Git — e.g., GitHub, GitLab, etc.
Do Code Reviews
When it comes to code reviews, it’s best to rely on peer code reviews. You can set-up a leveling system wherein if the code achieves a specific standard, you can commit to code changes. But you must have some type of code review in place before committing.
Commit Comments
Standardize your Git comments when you commit code. This way, everyone in your organization understands the purpose of the code — the comments act like documentation for your code.
Configure a Build System
You’ll need a system to automatically compile your code. If you’re using Java, you’ll probably use Maven or Gradle. For Ruby, you’re looking at Rake, while Yarn works best for Node.js.
Use Dependency Management
You’ll need a dependency management system — like Artifactory or Nexus — to create artifacts. This will enable the system to generate an artifact containing the version history of your code each time you compile it. You can then organize those artifacts using a versioning system, e.g., you can have a major build, minor build, and an actual build number.
The next step in your release process is to deploy immutable (i.e., unchangeable ) artifacts to one environment at a time. First, start with development, move to testing, and then send to your production environments. In case of failure, your release automation system should be able to roll-back to an artifact in a good state.
Configure Static Analysis
The goal here is to ensure your application can run tools that check for performance, security, and other key elements.
Set-Up Automated Tests
First, you should be doing test-driven development (TDD). TDD involves a process called “red, green, refactor.” The basic idea of this process is to write your tests first, get them to pass, then refactor by improving upon the original code. Second, you should test at the smallest unit possible to ensure your code works.
Generally, you should test at least 70% of your overall code, but 100% of your functional code. In other words, test all code that does something. Third, employ integrated tests and journey tests to ensure that the application as a whole runs the way you intended. If you have a build that fails any of your tests, kick that build out.
Mitigate Risk
Blue-Green Deployments
You can reduce the risk of downtime by using blue and green deployment techniques. Basically, you maintain two parallel production environments. Keep one (e.g., blue) active for traffic, while also keeping the other (e.g., green) on standby. You can use green to test new builds/versions of your application. This way, you avoid putting blue at risk of bugs and, in turn, you can find and clean-up bugs on green.
Use Canary Testing
Alternatively (or in conjunction with blue-green), you can roll-out updates to a subsection of your users first. In case there’s a problem, you can confine that problem to that specific user group — i.e., avoid downtime across your entire end-user base.
6. Network & Security
Create custom virtual private clouds (VPC) and, in turn, subnets for each VPC. You should also set-up access control lists (ACL) to limit what traffic flows between your VPCs. Finally, configure security groups, static IPs, and DNS. In terms of security, encrypt network connections. You should also set-up a Bastion Host to keep all your instances behind a private subnet. Your instances shouldn’t directly be accessible to the internet. Finally, build a strong password management policy and do a security audit.
Insights on How to Cut Your Cloud Development Costs & Lead Time:
- The Challenges Faced with Kubernetes Deployments
- What Does ‘Application Modernization’ Mean?
- Cloud Foundry vs. Kubernetes: Which is Best for Your Needs?
Next Steps to Using this Software Release Checklist
The challenge with this — or any — software deployment checklist is that each task is, in a way, an entire development project in of itself. You need skilled experts and tools for each section of the development stack. If you lack resources in any (or all) of these areas we covered, Techolution can partner with you by providing experienced application and development experts on a fractional or whole team basis.
At Techolution, we help organizations deliver market-ready cloud-native applications in weeks. Don’t let a lack of in-house expertise or resources stall your cloud deployment efforts. To see a few of our many varied enterprise AppDev projects for startups to global enterprises, visit our Portfolio. Then, contact us today to get started.
