In Part 1 of this article, we presented an overview of Amazon AWS and GuardRail, and discussed how the two marry the best in cloud computing and DevOps. We also learned how GuardRail is not just the premier solution for configuration monitoring, control and automation of AWS offerings like EC2 and S3, but can also work with any number of RESTful services. But enough waxing philosophical—time to put theory into action. And what better way than to follow a fictional organization as it sets up GuardRail monitoring for its AWS cloud infrastructure?
It's not pleasant to think about, but the fact is that when we go to work we are expected to do things. But what are the things that need doing? If we can answer that question without hours of meetings or dozens of emails we can finish our work and do...other things. GuardRail's new Tasks feature provides a lightweight project management system designed especially to maintain quality in a rapidly changing environment.
In July of 2014 Jon Hendren, also known as @fart, began a journey to become a DevOps thought leader. Using his audience of 70k+ followers on Twitter, he spread a simple message: Jon Hendren is a DevOps thought leader.
Over the years, Amazon has become the poster child for all things cloud-related, and for good reason: as one of the initial vendors to embrace the cloud computing paradigm, they were the first to offer widely accessible commercial cloud infrastructure services when it launched EC2 and S3 as part of AWS back in 2006. And now, almost a decade later, the tech giant continues to dominate with a 27% market share of the cloud services market. It's therefore not surprising that for many, Amazon comes to mind first when thinking of cloud computing.
When we set out to create a cloud-based tool for configuration monitoring, we used the tools we knew and wrote GuardRail using JRuby. For our application, JRuby had many good qualities: getting started only required a one line install, the agent only needed to talk out on port 443, and it was platform agnostic. Using JRuby we demonstrated the value of system visibility, attracted our first cohort of customers, and raised the funds to expand ScriptRock. Now we're not only scrapping that agent, we're moving away from agent-based architecture altogether. Here's why.
In a recent episode of the Enterprise Initiatives podcast, our own debonair cofounder Alan Sharp-Paul sat down with host Mike Kavis to talk DevOps, and especially one particularly memorable blog post in which Alan advised that's not wise to look before you leap and "don't automate what you don't understand." That point has been known to cause some contention among certain DevOpserati who often maintain the movement is primarly based on a cultural shift coupled with automation.
This week Qualys announced a vulnerability in certain versions of glibc that is now being called GHOST. The vulnerability allows remote execution of code by calling gethostbyname() and is considered critical. We won't cover what others have already said: you can read the original Qualys post here, a summary from ZDNet here, and advice on updating your OS version here. If you aren't sure what version of glibc is used on every one of your Linux machines, read on. We have created a one-click solution for validating the security of all your nodes.
This blog post will be a reflection on our recent experience of porting a reasonably large (~30KLOC) JRuby application to Google Go, talking about the many things we liked about the language and ecosystem, and the couple of things that I found grating about it.
GuardRail was initially designed to solve the problems we faced every day in the world of enterprise IT. Technical debt, documentation rot, and configuration drift consumed untold hours of our lives. GuardRail was designed to make those problems a thing of the past.
As a trusted partner of financial institutions, healthcare providers, retailers, and businesses of all kinds, we take seriously our responsibility to securely handle your data. The architecture of GuardRail, based on our years working at Australia's biggest banks, defends against one line of attack. The executable CIS policies we've created give you a push-button solution to validate server configurations and expose areas in need of hardening on your end. Now we have introduced two factor authentication to protect against leaked credentials.