Developers approach problems differently than operations folks do. With software engineers, the solution often involves code, but they have limited visibility into cloud operations. The advent of DevOps means you can quickly move to a low-latency state, where developers and cloud operators are often one and the same—or at least they're on the same team.
With CloudOps, developers need to think more about cloud operations and how to provide security because more of the operational and security responsibilities flow back to the software engineers. That means you need to take a different approach to coding, testing, and deploying applications.
In this article, I'll guide developers through the cloud landscape, and what's changing with cloud operations and security in three areas:
- The new process: How cloud and DevOps changes the roles of developers
- The technology: What automation technology makes these links possible
- The changes: How to push for change in your organization
The heart of the issue is for the developer to understand the target platform on which the applications will run. While software engineers have had access to test platforms in the past, now they must deal with staging platforms and production.
You'd think this would complicate a process that's already complicated. But in reality, the tighter coupling of developers with production platforms makes the applications better, both in terms of operations and security.
Why? Because developers in the past looked at operations and security as somebody else's problem, and so didn't put in the effort to build software that provided for good operations and security. With the advent of concepts such as DevOps, which includes CloudOps, the developer plays a central role, and as such is held accountable; not just for problems with the software, but with related operations and security issues as well. While you still have operations professionals in the mix, their role is more about setting up automation, monitoring, and providing a stable platform than making sure that the software runs successfully.
That's why things need to change. Developers need to become smarter about operations and security, and they must take steps to understand the target platforms, including operational behaviors. While it's unnecessary to become a security specialist, software engineers do need to understand how to include security and systems considerations in the design and coding of an application. They must also learn how to test applications to detect security risks, and then correct them.
A new process for developers
How are cloud and DevOps changing the role of developer? In the past, developers served a single purpose: to code and create software. While placing developers within the traditional waterfall processes seemed logical, it left a lot to be desired when it came to speed and efficiency.
Enter DevOps, which means continuous everything, including integration, development, testing, deployment, and operations. The idea is to remove developers' constraints and allow them to work from solution requirements to solution deployment, using as much automation as possible along the way.
DevOps breaks down the barriers that existed between developers and operations, pushing the groups and the individuals within them together. In some cases, they become the same person.
Some organizations may question whether developers are ready for operations. The larger question is, do they understand anything about proactively operating the target platform? And these days, more often than not, that platform is a public cloud.
In the new process an iterative exchange takes place between the developers and operators. Developers, hopefully with a new understanding of operations and security, take steps to ensure that applications are built around the needs of operations, with security in mind.
Typically, things that should concern developers now include:
- How to place monitoring points within the application that'll allow automated operations and monitoring tools to understand when operational issues exist and must be corrected.
- How to place security hooks inside the application to leverage platform-based security systems, such as identity management and encryption.
- How to automate the processes to promote an application to continuous integration, testing, staging, and then deployment and operations.
- How to take responsibility for issues with operations and security, and accept judgment on their knowledge and abilities in this area.
The technology: Using automation
What automation technology makes these links possible? There's no one-size-fits-all approach to this problem. The best practice is to evaluate your own DevOps process and look at items that you can automate.
In terms of operations and security, configuration management, testing, and deployment are the first places to automate.
Configuration management is about automated infrastructure, infrastructure as code, and programmable infrastructure. This is where you determine how the application will define the deployment platform, or how the infrastructure will adjust to the application's operations and security requirements by using pre-built automations.
Application deployment tools, which enable the automation of releases, are at the heart of continuous delivery, one of the primary tenets of DevOps. These tools let developers define just how the application should behave in operations and security services. You can also script them in sophisticated ways to automate the evaluation of features you need in the application to support operations and security. This includes the way that the application is tested, staged, and deployed.
When considering ops and security, the best practices in automation are mostly around monitoring. DevOps requires two types of monitoring. Application performance monitoring tools enable code-level analysis and correct performance issues. At the infrastructure level, server monitoring provides visibility into capacity, memory, and CPU consumption so developers can fix issues as soon as they appear. The key is to make sure that developers can see the data so they can make better calls during the development process.
Finally, you need version control; not just for your application code, but in your infrastructure, configurations, and databases. The payoff is a single source of truth for both your application code and your platform that you can use to quickly identify where things went wrong, and then automatically fall back to a known state.
Rolling with the changes
How do you push for change in your organization? This is a people issue, not a technical one, so the best path to change is to provide the training and mentoring around security and operations that your developers require. In some extreme cases, this could also mean changing the developers entirely, displacing those who aren't well-equipped to accept the changing roles, and changing to processes that better align with DevOps and the cloud.
The best way is to work with small and then large projects. Start out with a small prototype, and a small, ad hoc organization. Use this time to understand the new skills and approaches that'll be required, as well as the new technology.
Be sure to consider the new role of the platform, which in most cases will be cloud-delivered. As platforms become centralized and virtual in nature, make sure that you take advantage of that model. That means using distributed development and operations, and all must reach into the same platform using a common set of tools.
Finally, make sure you look at process changes first. Things are going to be a bit chaotic and overly interactive in the beginning, so you need to strike a balance between the innovative and fast-moving DevOps processes and organization. DevOps must ultimately have enough rigor to ensure that the resulting systems in both development and operations can deliver the value the business requires.
It's all about the platform
Adapting to cloud is really about the changing platforms. You're moving from on-premise systems to the cloud, and developers need to understand the new platform. As a developer you must deal with two dimensions; how well the applications operate on the target platform, and how secure they are.
Those in traditional IT operations might find the idea that developers should be charged with ops and security laughable, while others may wonder why we didn't do this before. In the past, developers were pretty much in charge of everything. Over the years, duties separated, leading to today's hugely unproductive development and deployment shops.
While DevOps organizations aren't looking to hand the ops and security keys over to developers just yet, they do expect them to learn more about how ops and security factor into the design, development, and deployment of critical applications. Responsibility and accountability need to be holistic, and there should be few separations of duties in the emerging world of DevOps.
As with anything new, you need to focus here on what works and what doesn't. That means consistently evaluating and correcting to new processes and automated tools. In some cases, enterprise IT may push too far and too fast into DevOps. In most cases, however, enterprise IT doesn't go far or fast enough.
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
