The Rise of DevOps and the Fall of Organizational Walls
Historically, IT organizations liked building walls. Infrastructure had access to hardware, system admins had access to operating systems and deployments, and developers wrote code. If you needed insight from a system, you found who owned it and asked for logs. Teams would get in war rooms when an issue occurred, and everyone would pull their logs to prove that the issue was not theirs. It was a time of ownership, but low collaboration. DevOps seeks to change that for the betterment of all teams and the overall improvement of how data is used.
With DevOps, organizations don’t deploy code from a DevOps or infrastructure perspective, developers do. When they check in new code, they are able to kick off the release process themselves. If any step fails, the developer has a similar set of buttons to roll back their changes. Developers have full access to their test and development environments, but otherwise, read-only access through limited channels to staging and production. From an infrastructure perspective, it’s a huge advantage. Organizations can release 1, 5, 10 or more times a day, and with no action required from a DevOps or infrastructure team member. Getting out of the job of release management frees the team up to do other things, but how do you make sure things are secure along the way?
The key is a tool that has build-time integrations and real-time tracking of data as part of the pipeline above. Security tooling can’t be just for systems and infrastructure teams anymore; it has to be valuable and accessible to developers too.
Cloud removes barriers to infrastructure and obscures systems
Organizationally, there’s little debate remaining that the cloud is the future when it comes to infrastructure. While there’s a myriad of reasons too long to list on why to move to the cloud – it also leads to a potential nightmare of security, permissions, and obscurity when it comes to systems. For example, with Amazon Web Services (AWS), there’s a role for every single thing you can do in the cloud, and administrators are quickly overwhelmed with managing these. Additionally, moving to the cloud is, or should be, about empowering teams outside of infrastructure to do more, and thus more teams can spin up and create new infrastructure. While technology administrators aren’t historically known for their world-class documentation, it certainly doesn’t help when more and more teams are continuously added and changed in the infrastructure as well.
Finally, the move to the cloud isn’t often a swift one. Legacy systems may be difficult or impossible to migrate as is to the cloud and at a minimum will take time to replace. Focus shifts to the modern innovation and walls are built around legacy monoliths. Soon the knowledge of these systems atrophies.
Data is everywhere, time is limited
One area where technology has certainly evolved and perhaps even exceeded the trend in is logging data. Over time, more requests have been filed to log more details about systems and changes. Logs are written to files in every conceivable location. Look at AWS and you’ll find CloudTrail logs, with a log of every action taken within your account. The amount of data available has grown exponentially with time, but the average operations and DevOps team certainly haven’t.
Time is a limited asset, and the effort of a skilled team member is certainly better spent looking through business and revenue impacting changes than pouring over a history of logs. In most organizations, there’s no way a team of persons, much less an individual could keep up anymore. A tool is needed that can take the work and automate it into a simple dashboard. The solution must bubble up the top actions from the myriad of alerts.
Proactivity over-reactivity
Finally, we’ve talked about the expansion of cloud in environments and with it the expansion of teams with access to the infrastructure within. There is a substantial need, a must-have, during implementation to do things right the first time, proactively, rather than reactive. Cloud environments allow for rapid expansion and development using new tools. These new tools move from internal development to production-ready with increasing speed, and ultimately this is what drives businesses to move to the cloud.
Teams must get ahead of poor implementation processes at the onset via a solid toolset. A world-class security tool must provide end to end proactive recommendations that can be applied to a cloud-based environment prior to or during the implementation of new solutions. It must be able to be reacted to just as a late-breaking security alert, and be implemented quickly to avoid building an architecture and platform built on a layer of insecure architectural debt.
Photo by Darrell Chaddock on Unsplash