Developers, operations teams, and business users have always been nervous about deployments because maintenance windows had a tendency to expand, causing unwanted downtime. It’s no surprise then that developers have always wanted visibility into deployments. After all, it’s their sweat and pride on the line. Operations teams, in turn, have traditionally guarded their territory so no one would interfere with their ability to get their job done. But the days of secret back-office deployments are gone.
When I started ReactiveOps almost two years ago, we set out to create a Ruby on Rails-like framework for AWS on the cloud – to stitch together the best open source components and write as little of our own code as possible, thus providing something greater than the sum of its parts. Our goal was to offer that infrastructure to small to mid-sized companies, enabling them to leverage the platform rather than hiring an in-house DevOps team and building their own.
Why outsource operations if you can simply hire a bunch of operations engineers and administrators and build and maintain your own infrastructure? It’s an important question. Let’s take a deeper look at the top 4 concerns small to mid-sized SaaS, web and eCommerce companies have about outsourcing DevOps work.
High availability is the expectation that a system will operate continuously for a significant span of time. For example, with 8,760 hours in a year, 99% availability signals over 7 hours of downtime a month and 88 hours of downtime over the course of that year. In turn, 99.9% availability—“three nines”—adds up to over eight hours of unplanned downtime, while 99.99% (four nines) translates into under an hour.
Lost data can mean lost business, so how can you make sure the cloud doesn’t bring you down? By keeping close tabs on what information has changed, who changed it and when. That means identifying all of the failure or disaster situations that can occur and their potential business impact – in advance.
Picture this – The operations team has spent months developing a hard-won understanding of technical bottlenecks and application-specific performance issues only to discover that this knowledge is no longer valid after a new feature launch fundamentally alters the way the app runs. The result? Slowdowns, errors and crashes. What do you do?
We’re all familiar with the most common threat vector – a hacker or other bad actor gains access to your cloud infrastructure to exploit system vulnerabilities. A less talked about threat vector is the purposeful or accidental deletion of data in house. Either way, the threat’s sure to become a reality some time or another. So how can you be prepared when that time comes?
Wherein we address the challenges in determining the kind of partner you should choose when seeking outside help with your cloud infrastructure.
5 Takeways from KubeCon—Kubernetes is quickly becoming the essential Docker container orchestration tool in the DevOps world.
If you don't monitor and log all the things, then you'll always be playing at least partially in the dark.
Leveraging a Platform as a Service (PaaS) is a great way to quickly build, innovate, and deploy a new product or service.
I’ve had my eye on Amazon’s Lambda and API Gateway services for a few months. Running a web application without the costs or headaches of maintaining servers is attractive. Of course, no platform is without tradeoffs.
Terraform doesn’t have support for conditionals on resources. There’s nothing like Ansible’s `when` statement to conditionally create Terraform resources based on a boolean variable value. At least not yet.
Riffs on microservices, docker, AWS, and serverless architecture/AWS Lambda.