Your development operation is extremely important. You already monitor your deployments, releases anyways. So why not automate the processes behind what can take hours, days, or weeks to monitor logs in five different places; perhaps, prepare an application you haven't deployed a release in months and the list goes on with scenarios.
The five pillars have been broken down into these themes:
- Meet Business Needs
- Develop your Pipeline as Part of Your Apps
- Continuous Improvement
- Self Service Features
- Track your Pipeline, Microservices, Compliance Policies
It is very important to think about the whole picture of your business and application. Before development, understanding policies, compliances, and other data-oriented securities is important to building a plan to keep your application unified to have a successful devops strategy. While there isn't an exact prescription when it comes to your application. It is important to look at your team and everyone involved in the processes to start figuring out how to build automation to speed up release times. Hopefully by the end of this article you will have to plan to create a successful cloud based pipeline for your applications.
The constant change in technology has created a NEED to adapt to hybrid computing for businesses to continue to support their monoliths and still stay current with newer architectures. Gaining visibility into all of your applications, environments is a key principle to hybrid computing and should be a goal for every company.
Hybrid cloud is a combination of mixed computing, services, and data storage that can be spun up in person, private cloud, or public cloud services. Public cloud is widely used today with Amazon Web Services (AWS) or Google Cloud Platform, along with other various platforms.
If you're using your public platform to send data to a private cloud or leveraging your SaaS applications and moving data between private resources - then you're already hybrid computing. Caring about your application matters. The goal of hybrid computing is to combine services, and data from a various cloud models to build a unified, automated, well-managed computing environment.
It is important to understand that if you're a compliance oriented organization such as those in finance, law, healthcare, and other securities - you will need private cloud services per meeting security compliances. If you're running an e-commerce store then you don't have to worry so much about this until you grow and need to start becoming compliant to a larger customer base.
Setting up your configuration, environment files is a very important step to developing a pipeline. You might have cloud-formation scripts to build certain stacks of your architecture and it would not be a good practice to setup just from the AWS GUI. The bad practices of setting up servers without any configurable way to spin up a new instance immediately will not work when creating automation.
It's very import to model everything to be reused in your application so that it is easy to maintain.
And don't forget automate everything: scheduled jobs, migration, compiling jobs, etc.
Don't forget keeping a repository for your application is key to being able to deploy. Setting up different environments in your codebase is an important part of the deploy process for your master release, staging, development branches.
Everything is a process. It is important to develop an architecture that can focus on helping your team work together better to produce great software. Deployments should be quick and easy when testing or releasing software and shouldn't be a burden on the team to have to spend hours or days to properly release.
A pipeline implementation will always need continuous improvement. When building out your continuous integrations (CI) this will be a time to think about the gaps between development and operation to automate building, tests, and deployments of your applications.
You might find it intimidating to learn Kubernetes, AWS products, Google Cloud products, Microsoft Azure products, etc. Or maybe your jobs product timeline has no room for you to spend time to delve into new technologies that can really help advance your application.
As a community we must spend time to look into new technologies and help advance communities. Even if it means we have to spend weeks figuring out and understanding how to implement such technology.
It is important to have confidence in being able to deploy. Release anxiety is not healthy for engineers as it can delay software releases majorly.
You should investigate ways your application will fail if a configuration file is changed or a file is incorrectly updated to the pipeline. What will happen? Well, you don't want to lock yourself out of your application nor have downtime - taking time to plan for ways to limit these possibilities will help.
One example of a fail safe - is knowing that if a configuration is allowed to be updated via console that may cause a defect if incorrectly implemented. You should then limit console access with specific roles to update root level files.
When making changes to configuration stacks it is important to re-deploy new versions (updates) from source code.
Adding a role to your architecture should be easy when you onboard new engineers. Spending countless hours figuring out access to things can be a tireless process to you and the your new teams to start development immediately.
Being able to have the ability to set your team up with tools to monitor their application day-to-day is key to the self service idea. It should never take hours or days to track down defects.
Utilizing integrations to run audits on the way you want your applications health to be is a way to keep a close eye on whats going on.
Having a general purpose dashboard to manage, or view your clusters will allow for you to troubleshoot defects, and manage clusters health of all your applications in different namespaces like: production, staging, develop.
A dashboard will also give you the ability to view cluster roles easily, active namespaces, nodes, pods, jobs, and the list goes on. Sometimes it is easier viewing these on a web page verse getting the data on the console.
Having a bird eye view of your micro-services running and an easy dashboard to view will make your life much simpler.
Using services like kibana, elastic search from elastic co help track your application in a birds eye view to see defects occurring through elastic apm.
Setting up roles for your engineering team and really understanding the roles everyone will have to the application is very important. If an engineer is only going to have access to navigate pods, application console, etc. and will never touch any of the development operations than their role should be different from those who will need access to root level files of the application.
You should setup compliance checks to be able keep track of roles and accuracy to application.