Written By Mick England, Director of Operations at True Fit Corporation
The first of the events was the AWS Meetup #10 at The Button Factory Dublin, which is attached to the Irish Rock and Roll Museum in the city's Temple Bar district. We often refer to “rock stars” in engineering, but mingling with the other speakers in the green room over sandwiches and beer surrounded by actual rock memorabilia added a special touch to this event.
Among the fascinating talks at this event, a stand out session in particular was Serverless Architectures on AWS by Sam Kroonenburg of the firm A Cloud Guru. Sam explained how A Cloud Guru provides AWS training for 20,000 users across 89 countries, without running a single server! By using Amazon services such as Lambda, API Gateway, CloudSearch, S3 and CloudFront, while offloading anything that is not providing their core services to 3rd parties, they are able to run a lean operation at a cost of just £50 per month.
After the AWS Meetup concluded, Steve and I took an early morning flight to DevOps World 2015 in London, an event that was very well-attended by large enterprise organizations including BBC, HSBC Bank and Mercedes-Benz.
DevOps sessions focused primarily on the topic of containerization and I had the opportunity to participate in a fishbowl discussion where audience participation is included. In this fishbowl, entitled “Docker Domination – Technology Fad or Development Dream?” My co-panelists included Dan North of Dan North & Associates, Steven Langton of Sainsbury's and Steven Acreman of Dataloop. Our discussion focused on the pros and cons of Docker, as well as appropriate use cases for the service. Here are a few key points from our discussion:
1. Developers love Docker because it provides them with an easy way to package their application once, and run anywhere.
2. Developers also love the speed with which applications can be created with Docker and the ability to easily expose network ports.
3. The increased speed and agility Docker brings can add hidden complexities to an application and have serious security implications.
In my opinion, Docker and other containerization tools are still fairly new and still developing in the industry. However, it is clear so far that containerization cannot be overlooked and there is a big demand for companies to continue focusing on expanding their monitoring efforts.
Performance Visibility in DevOps
This continually increasing demand for monitoring brings me to the topic of my presentations at these events: “Visibility in DevOps and Why the Choice of Monitoring Tools Matters.” As I stated at these events, I am not an employee of LogicMonitor but someone who has been using the product since 2009. I have seen it grow from a powerful SaaS hosted data center monitoring tool into a hybrid model for data center and cloud – specifically Amazon Web Services – with new cloud functionality unveiled earlier this year. My talk focused on the importance of monitoring in a DevOps workflow. Here is an image that I wish I had found prior to my panel to include it in my presentation:
In my opinion, this image represents the inconsistencies with current thinking regarding monitoring in a DevOps environment. This image demonstrates how monitoring positively informs part of the necessary feedback for code and deployment planning. But what is wrong with the loop depicted?
What’s wrong is that monitoring is at the end of the process, applied only after the code is operating in production. What I emphasized in my talk is the need for monitoring to be seen as an integral part of testing. This is how I illustrated this point in my deck:
This diagram is a modification of a popular workflow diagram where there is usually a Jenkins screen representing continuous feedback on the state of the build. In my version, I replaced that with a graph depicting a CPU spike. The key takeaway is not that build feedback is unimportant but that monitoring has to be seen as an integral part of testing -- not something done only in production, but across all environments.
I have seen environments where this is understood from the standpoint of application monitoring. Tools like New Relic or AppNeta's TraceView are used to establish a bench-line of how the application should perform and this is used as one measure of the success of a code check-in. Even in these environments, systems monitoring is seen as something for operations. Monitoring is there to tell us if production is functioning correctly. As long as our end user metrics are being met, why should dev care if CPU usage increases after a code check-in? That's for operations to deal with in production.
To illustrate the importance of introducing monitoring early in the development cycle, I used the example of a cloud deployed application utilizing autoscaling. One may be paying due diligence to the application baseline and be confident that they are going to meet their SLAs after deployment. Autoscaling will ensure this – but at a cost. For an application with a large user-base, that badly formulated database query causing CPU spikes can turn out to be very costly. Wouldn't it have been better to know that the latest release required more resources than the last? By monitoring systems early we can make better decisions and keep cloud costs under control. We can also avoid nasty surprises for our operations people.
In my discussions of DevOps, I tend to stay away from recommending tools as I consider them secondary to the cultural aspects of DevOps. There are however a number of important considerations in choosing a good tool for systems monitoring that I shared in my talk including:
My rationale for choosing LogicMonitor included the following points:
My focus on eliminating incoming connections was well received with the DevOps audience as large enterprise organizations are frequently constrained by a number of compliance regulations. LogicMonitor's security model only requires only a secure ssl connection back to their cloud and does not require incoming connections.