devopsy.kinsta.cloud

Category: Blogs

5 Prerequisites for a Successful DevOps Initiative

There are certain tools and attitudes that are essential to any successful DevOps transformation.

The manner in which a DevOps transformation is performed will have huge implications on the level of agility the company is able to achieve. However, before that point is even reached, some vital foundations must be laid. It is from that foundation that any innovation occurs. With that in mind, each of these elements are equally important, and should be regarded as such.

Consensus

Your first achievement on the road to successful DevOps should be an agreement on what DevOps means to your company and how it should be applied to your needs. Consensus on a strategy is almost as important as the strategy itself and must be in place before a detailed road map is constructed. Remember that DevOps is subjective and its implementation should vary from company to company. Consensus hopefully will be easy, but if not, it must be built by persuading doubters of the need for certain principles and practices selected.

This is the first step on a cultural journey; the collaboration between Dev and Ops staff and their consensus on a plan could make or break the DevOps idea. The concepts behind the initiative need to be agreed on from all corners of IT, as well as the business and any other key stakeholders such as suppliers. It is important the cons and pros of switching to DevOps are made clear for a balanced proposition. The argument for a shakeup on this scale needs to be compelling and justified for it to go ahead.

Consensus also involves handling expectations. To keep everyone happy there must be metrics and approximate timelines set in place so everyone knows what to expect and when, to avoid conflict further down the line. Only once consensus has been achieved and the basics are put in place can a more detailed road map be built.

Flexibility

A thorough road map is the skeleton that allows its muscular teams to flex independently toward a common goal. However, flexibility without allegiance to the agreed principles can cause chaos. The DNA that runs through all teams stays the same but applications vary, and so teams need to work autonomously if they are to cater for the specific needs and nature of the app they are working on.

While the road map gives a structure and handles expectations, DevOps culture needs to be tied to business outcomes and not formal internal milestones. Each DevOps team needs to be trusted to interpret the road map as it suits the specific project they are working on. Agile methodologies must be used, of course, but their interpretation is devolved to the teams themselves. This license and trust is key in allowing DevOps teams to react quickly and mold around the needs of the individual application.

Teams need freedom in terms of what tools they use and to an extent, how they use them. The methodology used to achieve the agreed core principles should have an element of flexibility. Tool-agnosticism is a must when choosing an automation solution for effective DevOps. Teams are happier and work faster when allowed to choose the tools that suits them best, making them more successful.

Automation

As C. Little said, “DevOps isn’t about automation, just as astronomy isn’t about telescopes.” An automated continuous delivery pipeline should underpin any DevOps initiative, adding consistency and reliability to flexible delivery methodologies. Tribal knowledge from Dev and Ops is gathered to create a pipeline that is the sum of the knowledge of its contributors. The pipeline is repeatable, and over time is made more efficient by rooting out inefficient manual processes. Modelling into a workflow helps all involved visualize where a team is in the app life cycle and what next steps need to be taken next and by who.

Trust in application release automation can be a big deciding factor in how companies achieve successful DevOps practice. Sometimes there is a culture within a company of wanting to have manual control over certain processes that inevitably slow things down. Automating any and every manual task possible is essential to speed up DevOps. If a manual intervention is needed, the relevant member of staff can be notified by the automation solution itself, which automates out the remainder of the task for which manual intervention is not required. Over time, manual interventions will disappear altogether.

The ability to give DevOps teams freedom in their tool selection keeps staff productive but adds yet more complexity and leads to a highly heterogeneous workplace. It’s important your automation solution has approved integrations to all tools DevOps teams might choose and also releases free integration to new tools quickly, so you can stay on top of the latest trends and continue to be successful.

Cooperation

Unless you’re a startup with heavy investment, you’ll likely be changing the structure and workload of your existing staff rather than hiring a new team suited perfectly to their individual roles. The success of DevOps depends on the ability to make positive change in the way team members collaborate.

Resistance to change may occur due to staff being accustomed to working in one particular way for a long time. However, this could also be down to personality type. As it is Ops and Infrastructure staff who face the biggest changes and are used to limiting rather than encouraging risk, often they can be the most resistant to change. Often devlopers do not have to change the way they work to the same extent, so fewer feathers are ruffled.

I have seen big corporations that do not have compliance from everyone, so their DevOps is limited in scope and unfortunately they will never reach full agility. Sometimes you must adjust your teams to ensure positivity to DevOps and receptivity change in general.

Rethink Architecture

I’m not saying DevOps cannot be implemented in legacy systems, but there are elements of legacy systems that make it hard to instill full automation and continuous delivery. What is important is that the organization is open to a certain degree of architectural change. Monolithic apps can certainly slow down a DevOps initiative—often it’s mainframe apps that are not built with a service-orientated architecture—so it’s important to know how to adapt them to fit your strategy.

A full architectural revolution is not needed to be successful. Obviously this is where cloud-native startups have an advantage as they can assemble their infrastructure from scratch, but there is no need to rip and replace existing systems for the sake of it and waste money. Certain elements of even the most monolithic systems can be modernized—for example, Siebel deployments can be fully automated so operations staff are free to concentrate on more demanding aspects of the cultural change DevOps involves.

DevOps applications can interact with legacy systems if we use the right techniques. Make sure your automation solution has integrations with the likes of SAP, Oracle and Siebel, and so enables legacy systems to be enablers on your digital journey rather than obstacles that will stand in your way as you seek to reach full DevOps and end-to-end continuous delivery.

May 10, 2016
Embracing a DevOps Culture, Part 2
In Part 1 of this series, we discussed the fact that more organizations are looking to embrace the “DevOps culture.” However, unlike ITIL, implementing DevOps into an organization does not happen overnight. DevOps is more a philosophy than a procedure, and choosing the right leadership team is as important as choosing the right tools.

In Part 2 we look at other important elements of organizations successfully embracing the DevOps culture.

Without Proper Collaboration, DevOps Initiatives Will Fail

A good test to determine if your organization has truly embraced the DevOps culture is how well your IT department responds when a major incident occurs in the product environment. For example, an e-commerce company’s dramatically slow website, a hospital’s unresponsive electronic medical record (EMR) system, and a malfunctioning airline reservation system. In these chaotic situations, every minute counts and all Dev and Ops hands need to be on deck to keep your organization afloat.

When incidents occur, it’s critical that your organization’s Dev and Ops teams work together to resolve the problem and restore failed service as quickly and efficiently as possible.

Incident Response: The Critical Incident Team

An international company with global operations may have network operations centers (NOCs) in the United States and the U.K. that support more than 50 mission-critical business applications, development centers in China and the United States and a service desk in the United States. When an incident occurs, the company’s service desk is flooded with alerts, ranging from various IT monitoring tools and customer phone calls to open tickets from online users and inquiries from stakeholders. When that happens, the only concern of the service desk is to fix the issue—not tracking down a department head on the other side of the world that may be responsible for the problem.

DevOps should enable an organization to assemble its critical incident team in only a few minutes. The Ops team should know exactly what team(s) to contact for a given incident, and who from those teams is assigned to application support. They should know who is on call based on the time zone and day of the week, and have the correct phone numbers easily accessible.

Next, the team should review the technical details of the issue provided by the incident manager. The universally used DevOps toolset enables everyone to speak the same language, quickly identify the root cause, put a remediation plan together to have approved by the emergency cab, deploy the fix, test it out and confirm service is back up and running.

IT Communication: The Glue That Holds Dev and Ops

To be successful, organizations need to be able to respond as quickly as possible during a major IT incident to limit the negative impact on the business. This is achieved when Dev and Ops works together to create a central communication and collaboration center to ensure proper communication with key stakeholders.

An organization’s ability to effectively mitigate the impact of an IT issue relies heavily on its ability to access and communicate critical information, and to ensure the right people can analyze it and initiate the appropriate actions to keep the business running smoothly. The communication hub equipped with an IT communication solution will facilitate:
- Reaching out to the right on-call people among all the different teams: infrastructure, server, system administration, middleware, network, DBA, QA, support team, service desk and the application developers.
- Because emails don’t wake up people, they will be able to leverage the IT communication solution to reach out to people via multiple channels until they respond (voice, SMS, email, push notification app, paging, etc.), or automatically escalate to the next resolver on the on-call list.
- Providing the right information so the IT resolvers start investigating the issue, identify the root cause and put a resolution plan together without wasting time.
- Get people to collaborate together using the same telecommunication and collaboration tools whatever the time zone and wherever they may be located.
- Contacting a third-party vendor in case the problem is not attributable to the company but caused by an external piece of software.
- Informing the other departments if the business impact grows so big that it affects the company profitability or reputation, such as a cyberattack leading to a data breach for instance. The CEO, legal and marketing may need to be informed to anticipate the consequences.
- Informing end users or customers to limit the number of incoming calls into the help desk.
The benefits of quick collaboration and not just handoff between the teams don’t even have to be demonstrated. Removing the broken pathways, obsolete delivery methods and redundant platforms will improve significantly the organization’s ability to communicate during critical moments. Becoming more efficient and removing the time wasted will automatically have a huge impact on the mean time to know (MTTK) and, in turn, on the mean to resolve (MTTR), hence minimizing the disastrous impacts on the business and keeping the company’s execs sleep at night.

DevOps Culture Can Happen

Embracing a DevOps culture is not a Big Bang change that happens overnight. This is a journey that will be more or less difficult to pursue based on the existing culture and the history and maturity of the IT organization. Even more importantly, it will depend on the level of commitment from upper management to introduce a new culture. Leaders need to embark on this journey keeping in mind that not only will it require new common tools and new common processes, but also they’ll need to convince people of the value of such transformation. To achieve this goal, management should consider IT communication as a key element, which will be the glue that binds Dev and Ops together. And because there always will be room for continuous improvement, the road to DevOps will have no end.

About the Author/Vincent Geffray

Vincent Geffray is Senior Director of Product Marketing at Everbridge with focus on IT Service Alerting & Communications Automation and IoT.

He has more than 14 years of experience in the information technology business, designing, promoting and selling Enterprise IT Operations Management solutions, including Critical Communications, Application Performance Management, IT Process and Workload Automation. He also has international experience as he started his career in Europe. Vincent holds a Master of Science (Mechanical Engineering and Computer Science) and executive certificates from the MIT – Sloan School of Management.

Vincent’s LinkedIn: www.linkedin.com/in/vgeffray

Vincent’s Twitter: @vgeffray
May 10, 2016
Truth and Consequences

— ROELBOB

May 10, 2016
London Calling: DevOps Enterprise Summit and DevOps Connect: CD Connect/Jenkins Days, 2 for 1
As is to be expected from a world capital city, London is also a hotbed of DevOps adoption. The local London DevOps community is thriving with a near constant stream of DevOps conferences. There are however two great events coming up that are can’t miss. DevOps Connect: CD Connect/Jenkins Days in May and Gene Kim’s DevOps Enterprise Summit in June are both in London. Now you can attend both for the price of one!

Right now due to the DevOps.com sponsorship of DOES London and the generosity of the sponsors of both events, if you sign up for the full £179 two-day ticket for DevOps Connect: CD Summit/Jenkins Days you will receive the full £179 back in the form of a credit towards your ticket for DOES London. You wind up attending CD Connect/Jenkins Days for free!

So what do you get from attending DevOps Connect: CD Summit/Jenkins Days and the DevOps Enterprise London? Glad you asked. Let me give you some of the highlights to look forward to.

First DevOps Connect: CD Summit/Jenkins Days:
1. Two-day event, day one features keynotes and three tracks, plus lunch, refreshments, exhibit area and demo theater.
2. Day two of the event are deep dive workshops on Jenkins, DevOps Transformation, automating deployment in Hybrid Clouds, DevOps Foundation and DevOps Lift off and the Nexus World Tour: Rugged DevOps Heroes Assemble. You can pick and choose which of these workshops to attend, there is on price for admission to all of them.
3. The event is being held at the KIA OVAL, KENNINGTON OVAL,SE11 5SS LONDON, UNITED KINGDOM.
4. The keynote and headline speakers for the event are pretty amazing:
Sacha Labrourey, CEO and Founder CloudBees, former CTO JBoss speaking on “Why Jenkins Has Become the Engine of Continuous Everything.”

Sanjeev Sharma, CTO & Distinguished Engineer for DevOps, IBM on “Adopting DevOps at Enterprise Scale.”

Gary Gruver, Author of “Leading the Transformation”, Previously executive IT positions at Macy’s and HP, speaking on Leading the Transformation: “Applying Agile and DevOps Principles at Scale.”

After this great morning of keynotes, there are three tracks all full of great speakers and topics after lunch. You really don’t want to miss this event and if you were planning on going to the DevOps Enterprise Summit London, you can go to CD Summit/Jenkins Days for free.

Why go to DevOps Enterprise Summit London? Well if you want to hear about the experiences of large enterprises in adopting DevOps, there is no better place. In the previous two Summits held in San Francisco, Gene Kim and team have done a great job of shining a light on “horses” DevOps transformations. This first London edition of the franchise promises to be equally as great. It will be held at the Hilton Metropole in London.

Some of the speakers scheduled to present include:

Gene Kim, Author, Researcher and Founder of IT Revolution.

Gareth Rushgrove, Senior Software Engineer, Puppet.

Jason Cox, Director, Systems Engineering, The Walt Disney Company.

This is just the tip of the iceberg really. There will be over 25 speakers at DOES London, as well as community space, breakout sessions and more.

While London has more than its share of DevOps events, I am not sure it has experienced the likes of these two events before. Please don’t miss them and look forward to seeing you there.
May 9, 2016
Hello, Security. Meet Agile
Illumio Chief Commercial Officer Alan S. Cohen recently wrote in his blog, “Go, Slow and No: Bringing DevOps Speed to IT Security,” “There are reasons why security and risk professionals often react with a ‘no.’ When you are tasked with assessing and reducing risk, going fast might not be the first instinct.”

Many InfoSec practitioners adhere to accreditation and certification programs such as ISO27001, SSAE-16 SOC and PCI compliance. This ultimately means they follow strict policies and procedures for software development. These procedures go through many gates, including risk analysis, design and code reviews, penetration testing and ITIL-based change-management processes. InfoSec teams live in a world where they have to plan their changes months in advance, and this world often is in direct conflict with agile development and DevOps concepts.

Agile is all about focusing on flow and end-to-end cycle time, releasing very small changes fast, early and often. It’s not about the number of things in each sprint, but rather what’s needed now for MVP and iterating. For agile and security to be in alignment, there needs to be a fundamental shift in the principles and values that enable the business over governance and process.

In particular, security:
- Embraces some uncertainty. You will never build a perfect piece of software. The key is to build guardrails and to have the required adaptive enforcement and monitoring in place to capture and correlate metrics that help you quickly respond, evaluate factors of compromise and leverage your deployment automation to remedy risk exposures quickly.
- Is part of the project team, either embedded or as an adviser. There must be a dedicated resource that understands the team’s mission of delivering value. Somebody on the team should be wearing the security hat, helping to guide each project.
- Is a risk adviser inside the organization. Don’t compartmentalize information. There needs to be a culture of trust, sharing and transparency about potential vulnerabilities to the service.
- Trusts the decision-making of engineering teams. Informed and capable engineers aren’t reckless with security decisions.
- Is part of everything. It’s the design of the entire service and therefore is the responsibility of the entire team, not just the security team.
- Improvements do not add complexity to the user experience. Security that degrades the user experience will force people into insecure practices.
Bringing Agility, Security Together

Embracing agility and DevOps opens the door to new possibilities that can improve security posture without hindering the business. Security will quickly discover a new set of best practices:
- Look to microsegmentation software that is adaptive and intelligent, to replace manual management of firewall rules and policy.
- Decouple security from the infrastructure to gain a continuous enforcement pipeline that adapts to new hardware, with strong versioning that proceeds in lockstep with product releases, monitoring and infrastructure configuration.
- Build security into the service stack; don’t bolt it on afterward.
- For change auditing, don’t rely on the change management database alone. This is highly prone to error and discrepancies. Look at the the git history integrated with the automated deployment system. Change management databases should be integrated with the git pull requests and commit logs. Infrastructure automation tools such as Chef and Puppet keep logs for unapproved change drift. Make sure those logs are being captured and reported on.
- In the area of developer support, DevOps is enabling the self-service/self-responsibility revolution by building wrapper abstraction layers for engineering teams to consume infrastructure across public and private data centers, using interfaces such as chat to trigger administrative actions and query metadata information on their instances. These wrappers can also be harnessed to present security grading for every server instance, promoting awareness and corrective action to each individual owner. You can quantify the grade by looking at patch vulnerabilities, images used to build, inbound/outbound port rules and configuration standards.
- For data at rest, data in motion and data in transit, everything should be encrypted, everywhere. For example, use Illumio SecureConnect to encrypt data in transit via IPsec between workloads. Automation and the right secrets-management infrastructure can enable frequent rotating of SSL certs and keys.
- Every time you commit to the code base, run a set of very basic security tests via your favorite continuous integration tool. Use automated tests to ensure common security mistakes don’t leak to production.
- Perform red team exercises as an attempt to gain access to a system by any means necessary. Try to mimic the same processes that a motivated attacker would follow to map out an organization’s infrastructure, perform reconnaissance at key physical installations, and then test the physical, cyber and social defenses all at once through a staged exercise.
Security can become an enabler. It no longer has to be stuck being the department of “No.” InfoSec can now be the team-building tools and systems that enable development teams to do what they want in a secure way.

About the Author / Alfred Garcia

Alfred Garcia oversees DevOps for Illumio, where he is responsible for all preproduction and production cloud/infrastructure engineering and site reliability. A technology and operations executive with more than 18 years of experience, Alfred is an aggressive advocate of DevOps and of deep operations and engineering collaboration, from design to code/test and release to production support.
May 9, 2016
Balance: The Key to Successful DevOps

In the realm of IT buzzwords, DevOps is in a league of its own. The pervasiveness of the word is matched only by the variety of its definitions. Over time, much like the parable of The Blind Men and the Elephant, it has slowly taken shape out of the void, albeit in a backwards fashion. Associated terms such continuous delivery, integrated quality assurance and deployment automation have helped backlight the beast’s silhouette, but there is much more to discover.

Generally, DevOps is defined by how it is used rather than what it is. This is helpful for those already familiar with the amorphous nature of the movement, but can be a confusing introduction for the uninitiated. To achieve a better understanding, it is important to grasp the underlying need driving the shift to a DevOps model.

Currently, the world of IT is barreling toward a future dominated by increasingly specialized and inherently complex automated solutions. Software is taking a front row seat in ways never before possible. (Insert here)-as-a-service offerings and the demand for instantaneous and consistent deployment turnaround is at an all-time high. The days/weeks required to shuffle a solution between development and engineering is a luxury that most companies can no longer afford and is less tolerated by customers. This level of expectation is something that the traditional IT org chart was not designed to cope with. Tech companies everywhere have felt the strain of this increasing momentum, with many at a loss of how to handle it. Demanding that teams work harder, faster, longer will only get so far. And inevitably, increased intensity results in a rise in mistakes and an inferior product.

Balance: Dev’s Yin to Ops’ Yang

Clearly, change was and is needed. The path from development to operations needs to be streamlined at a fundamental level. However, dissolving the barriers between two longstanding departments is not without its perils. As any IT veteran will tell you, development and operations each have their own cultures, quirks and personalities. But the differences in each help create the perfect balance.

In its purest form, development is the trailblazer, forging into uncharted territory and unearthing hidden gems. Ever the innovator, Dev values progress and change above all. This constant forward momentum is Dev’s greatest asset as well as its Achilles’ heel. The habitual urge to tinker, tweak and create can lead to frivolous or wasted effort. The results of this misguided effort can be seen in retrograde patch releases, hotfixes and other “band-aid” measures needed to undo the damage.

On the other end of the spectrum, the operations mantra can be summarized with the idiom, “If it ain’t broke, don’t fix it.” Pragmatic to the core, stability and consistency are the guiding forces behind Ops. Change requests are usually met with a Treebeard-esque, “Don’t be hasty.” Taken to the extreme, this mindset can quickly lead to an environment running outdated, unpatched software and end-of-life hardware.

On the surface, the differences between these two groups appear to be on the verge of irreconcilability. However, in this diversity the beauty of DevOps emerges as the strengths of each team balances out the weaknesses of their counterpart. Development is free to innovate and create knowing that their efforts will be guided by feedback from operations. Like stabilizers on a rocket, operations is able to focus on maintaining a reliable infrastructure with development providing the forward momentum. Working in unison, this duo forms a unit far greater than the sum of its parts. And with it, a company is left with an agile and stable launch pad from which to tackle the latest wave of IT challenges.

Admittedly, the combining of development and operations into a single cohesive unit is just a piece of the entire DevOps puzzle. However, it is an important piece that is frequently overlooked. Understanding the forces and motivations at work within your teams is a pivotal step on the road to a successful DevOps transition.

About the Author / Jared Perry

Jared Perry is a cloud engineer at iland, where he is responsible for maintaining the virtual infrastructure and a number of disaster recovery solutions. He holds a Bachelor of Applied Science in technology management and a Bachelor of Science in IT administration and management from Texas A&M University.

May 9, 2016
Q&A: Sematext’s Thies on Docker Monitoring, Part 2

In part one of my conversation with Stefan Thies, Sematext DevOps expert. we spoke about Docker’s use of Sematext Logsene logging, anomaly detecting and alerting software and SPM monitoring software. Let’s continue the conversation.

David Geer: What makes Logsene centralized? Where is it centralized a typical deployment? What are the advantages of it being centralized?

Thies: Traditionally, systems store logs from multiple applications on every server. This makes it difficult to search logs for troubleshooting or auditing purposes. To find a relevant log entry, operators must log in to each server, find the right file on this server and search in this file for a relevant message.

This can easily take several minutes. With systems storing logs on multiple servers, it is difficult to correlate data, so minutes can turn into frustrating multi-hour root cause-hunting sessions, often involving multiple team members. Logsene provides a central full text index for all log data coming from multiple servers and applications. There is no need to log in to multiple servers and search/grep multiple log files. All team members see all data at the same time and can collaborate much more efficiently.

Having a central place for search makes it much easier to find logs quickly, run analytic queries or centralize alert rules in a single place.

Geer: What is it about what Logsene does for Docker logging?

Thies: Sematext Agent for Docker interacts with the Docker API to automate the collection, parsing and processing of logs, metrics and events. It detects containers automatically (no setup or configuration for a new container!) and supports many log formats for applications on Docker Hub such as Nginx, Apache, Elasticsearch, Solr, MongoDB, MySQL and many more.

Geer: What does your statement mean, “Some DevOps engineers even think of Logsene as ‘ELK Stack on steroids’”?

Thies: The ELK Stack is a combination of open source tools: Elasticsearch, Logstash and Kibana. These tools are very popular for log shipping (Logstash), indexing and search (Elasticsearch) and visualization (Kibana dashboards). However, these tools are missing many enterprise features like multiuser user interface, role-based access controls, secure transport of logs or out-of-the-box configurations and an easy query language to search logs. This is where Sematext Logsene adds the relevant enterprise features to these open source tools to make them easy to use and securely integrated into the enterprise information technology infrastructure.

Maintaining Elasticsearch clusters is another problem for many people. It requires a lot of expertise. Using Logsene does not require this sort of expertise. The Logsene SaaS provides a managed solution where users don’t need to know anything about maintaining Elasticsearch clusters or the required infrastructure. Sematext takes care of that for them. Sematext customers can benefit from these managed services and pay a fraction of the cost compared to self-hosted ELK stacks, where storage, computing and networking infrastructure and manpower for highly skilled workers counts.

Geer: What is Tutum? What is so important about ease of launching SPM and Logsene Docker on Tutum?

Thies: Docker acquired Tutum in 2015. Tutum provides management of Docker containers as a cloud service. Tutum is a platform made to operate “Dockerized” application stacks. In the case of Sematext Agent for Docker, the Tutum integration deploys Sematext Docker Agent automatically to all cluster nodes in a few seconds. These nodes could run on different cloud platforms such as Amazon, Digitalocean, Rackspace or on premises. Again, a big time-saver for people running larger infrastructures or hybrid clouds. Supporting Docker products and having excellent integration with Docker products is important for Sematext.

The Sematext Docker Agent runs on all solutions offered by Docker e.g., Docker Swarm and others such as Google Kubernetes, Google Container Engine, RancherOS, CoreOS, Amazon ECS or Hashicorp Nomad.

Geer: Please discuss the Sematext Docker and Docker image?

Thies: Sematext Docker image is available on Docker Hub, and we shared the Tutum Stackfile for Sematext Docker on Stackfiles.io. The easiest way to get it is to use Sematext, which generates the stackfiles for you, including tokens.

Docker Hub is the central registry for public application images including related installation instructions. Docker users can find out quickly how to run a “Dockerized” application with the help of the instructions in Docker Hub. Typically, this requires a little configuration work before a container can be started with the right settings.

Stackfile.io is the place where people share preconfigured application stacks (e.g., a web service together with the required database). Sematext provides a preconfigured setup for Sematext Docker Agent to monitor all containers in Tutum Cloud. This means one can launch Sematext Docker Agent and monitor all containers running in Tutum Cloud with just a single click for the chosen stack file and by entering a unique identifier (Token) for the application. That is really all it takes.

When you log in to Sematext SPM or Logsene the general installation instructions have all required configurations displayed. Sematext users can simply copy/paste the relevant commands including unique identifiers (tokens) for their application to get the Sematext Docker Agent deployed. This, too, is a big time-saver for our users and it gets them up and running in just a few minutes.

May 9, 2016
Most Valuable Vendor

— ROELBOB

May 9, 2016
Why Is There No DevOps Manifesto?
Let’s start with a brief story:

There’s a scene in a movie called “A Few Good Men” in which a lawyer is questioning a cadet. The lawyer directs the cadet to turn to the page in the thick Marine Code Manual that explains where to find the canteen. And the cadet replies, it isn’t in there.

And the lawyer says, “Well, you eat, don’t you?”

And the cadet says, “Yes, sir, three times a day!”

The meals for everyone aren’t served by the book because the canteen isn’t included.

This isn’t a history for the term DevOps or of the many people who’ve led, presented, written and interviewed about the DevOps movement. I’ve got a footnote below with some pointers for that. This is simpler than that: It’s why today there is no DevOps Manifesto and why I don’t think there will ever be.

Now, I think I understand the desire for a DevOps Manifesto. I’ve met a lot of folks, company executives and analysts, who still dis DevOps a bit because it lacks a certified definition, an official manual or a definitive statement. Basically, a manifesto; you know, a canonical thing you can put on a shelf.

Manifestos can be nice. They lay down the vision, the intent, the mission. They can appeal to a wide range of people, from revolutionaries to functionaries to dignitaries. It isn’t for sparking conversations so much as for orderly setting down of intent. A manifesto can bake in the meaning and content of something.

A manifesto has that “rule of law” book feeling to them. Manifestos also have provenance and pedigree—some group of some renown sat down to discuss some topic for some specific resolutions and wrote the sum of it up. Manifesto wording can be checked to ensure real-world compliance.

You can almost slap a copy of a Manifesto on a table to settle an argument about the manifesto’s topic. And assuming the words were crafted carefully enough, it will be the end of discussion. And that’s exactly the problem with a manifesto with respect to DevOps.

I say: That’s not what DevOps is about.

DevOps begins with stopping the nightmare scenario pitting Ops against Dev—or any other part of the organization. But it comes so much further. It’s for a new age of computing at webscale, using tools, teamwork and techniques to get to better, happier, more engaged outcomes for customers. Some of it is so new we are still figuring out words for it.

The DevOps movement isn’t slowing down, either. Analysis of the Google results page shows it:

In all of this time, no one of any significance in the community has attempted to create a “manifesto for DevOps.” I’d say the Godfather of DevOps himself, Patrick Debois, was super insightful on how he went about ensuring no official manifesto could get written. (I’m not going to review the lessons learned from “The Agile Manifesto,” although good lessons were learned from the things created in the wake of having an Agile Manifesto.)

If you have a manifesto for something, then all conversation in the domain will, rather quickly, go back to the manifesto for resolution instead of everybody working together. That’s not handy in an ever-fluid, often on-fire, scale-up fast, resilience-oriented, rapidly changing and evolving IT situation.

As Andrew Clay Shafer (@littleidea) said recently, DevOps is about optimizing for people. With the pace of IT and tech ever accelerating, no manual or manifesto could keep up. Which reminds me of one of my favorite quotes:

Companies die because their managers focus on the economic activity of producing goods and services and they forget that their organization’s true nature is that of a community of humans.

— Arie De Geus

One thing you should know for sure about DevOps: The community likes to enhance, educate, enliven, inform and energize people. Basically, everyone is wide open to embracing anything that helps out because webscale is hard. So yeah, DevOps now aligns with “microservices” because microservices can further the DevOps cause. Just like kanban, Docker containers, automated configuration and InfoSec. And anything that enables Dev and Ops to deliver more, better, faster to customers. It’s about serving the customers.

Meanwhile, if you’re looking for more, you’ll usually find a bunch of folks … figuratively speaking … over in the kitchen at the canteen, serving up awesome and working hard on doing it better and faster.

And everyone interested is welcome to sit down and enjoy what’s served.

Seriously. Join in. You do not need a manifesto to.

P.S. It was with deep hesitation that I wrote this. There are simply so many awesome people who’ve made all this happen and I am not one of them. Literally the finest collection of technologists—and in many cases, human beings—I have the honor to know who make this community what it is.

You should check out, in no particular order:
- The amazing (and amazingly modest) Patrick Debois
- The writings and teachings of Mark Burgess (one of the most under-recognized geniuses I have encountered)
- The CALMS write-ups by John Willis (@botchagalupe) and Damon Edwards (@damonedwards)
- Damon’s five-minute video on DevOps history
- John’s frank exploration of the issue of burn-out in IT (and that is directly related to why we are having DevOps conversations)
- Mary Poppendeick’s lean development work
- John Allspaw and John Hammond’s 2009 Velocity keynote that sorta kicked this whole thing off
- Ben Rockwood’s (@benr) comprehensive LISA11 keynote
- The many videos of Andrew Clay Shafer (@littleidea) and his brilliant guidance. Sometimes with katana and sometimes with gattling gun.
- Jez Humble’s books (particularly “Continuous Delivery” and “Lean Enterprise”)
And works from folks including:
- Jeff Sussna (@jeffsussna)
- James Turnbull (@kartar)
- Adam Jacob
- John Vincent (@lusis)
- Bridget Kromhout
- Adrian Cockcroft
- Gareth Rushgrove
- Kris Buytaert
- J. Paul Reed
- Ernest Mueller
- James Wickett
- Ines Sombra
- Karthik Gaekwad
I mean, this is a global phenomenon, were you expecting a short list? This isn’t even complete!

Oh, and the VisibleOps guru Gene Kim, who came and showed us all a way to really blow the doors off the DevOps news.

These people are helping all of us do better Dev, better Ops, better IT, better business so that you can have better customers. It’s amazing. It really is. And it’s wonderful.

Also, if you get a chance to spend time at a DevOps Days anywhere, you should.
May 6, 2016
Continuous Delivery: The Atlassian Way

Sonatype’s Mark Miller (@TSWAlliance) caught up with Ian Buchanan (@devpartisan) for our 2016 DevOps Leadership Series. Ian discussed his experiences at Atlassian, including continuous delivery, ChatOps, and use of tools such as Bamboo, Nexus, Puppet and Datadog.

https://www.youtube.com/watch?v=MgRaYKHGqeQ

Buchanan: I’m Ian Buchanan. I’m a Developer Partisan at Atlassian, which is developer advocacy for our developer tools.

Miller: Ian, most people know Atlassian from solutions like JIRA and Bitbucket.

Buchanan: Yeah, I focus mostly on Bitbucket and Bamboo. Bamboo’s our continuous integration and deployment tool.

Miller: Good. One of the subjects we talked a little about at dinner last night is how Atlassian is using Nexus. Can you give us some background on that?

Buchanan: Yeah, that’s right. Well, we’re a big Java shop. We have been for a very long time and have a lot of Maven dependencies for external reasons; we also store a lot of our own internally developed libraries in our Nexus repository.

_________________

We’re a big Java shop. We have been for a very long time … we store a lot of our own internally developed libraries in our Nexus repository.

_________________

Miller: As far as a binary repository, are you using it for anything other than components?

Buchanan: Not that I’m aware of. I know that we’ve recently started to get into Docker quite a bit and Nexus is a good fit for that as well. I don’t know the extent which we’re using Nexus for that purpose yet, as Docker’s still quite new for us.

Miller: What does your continuous integration pipeline look like?

Buchanan: It certainly varies by product in the details. Of course, we have our own continuous integration product, Bamboo. Bamboo is the most pervasive tool we have.

For the Java stuff it’s pretty simple pipeline where libraries get built and published into Nexus so that they can be used downstream. We also have some interesting, newer cloud products that are built with Python. A lot of the deployments, whether they are Java or Python stuff, are handled by Bamboo’s deployment projects. They pull artifacts from Nexus and put them into production.

_________________

A lot of the deployments, whether they are Java or Python stuff, are handled by Bamboo’s deployment projects. They pull artifacts from Nexus and put them into production.

_________________

Miller: Are you guys using continuous delivery in house for your workflow?

Buchanan: We’re in an interesting position that I think I see a lot of companies in. We have some behind-the-firewall products (our server products) and then we also have cloud products. In the cloud side, continuous delivery is used when we want to go very fast. But we also have to balance that with the approach we take for our server products so that they don’t fork terribly. We have continuous delivery up until there’s a product delivered. At that point, there is another kind of pick up—where the cloud products engage with other things like Puppet and Ansible to configure the environments with products that other people can pick up and run on premises.

Miller: I was talking to your team in San Francisco. How are you guys using ChatOps with HipChat?

Buchanan: I’ve been talking about ChatOps for quite some time. We do a lot of very interesting things with ChatOps. They play a very important part of our continuous delivery pipeline in that we publish build results in there. People can see when pull requests are ready and check those out. We get to see what’s happening from production as well. We have integration with Datadog; it tells us some of the monitoring things that are going on. It’s not just information coming into the chat room. There are also commands that folks can issue to make the continuous delivery pipeline move along. There are certain stages where you can type a command to our ChatOps and they will perform the necessary actions. Much of the deployment and change management happens in a ChatOps context.

_________________

There are certain stages where you can type a command to our ChatOps and they will perform the necessary actions. Much of the deployment and change management happens in a ChatOps context.

_________________

Miller: Anything coming up in the future you guys are working on that’d be fun?

Buchanan: Well, a lot of the innovation really happens at our quarterly “Ship It” events. That’s where our developers spend 24 hours doing whatever kind of innovation interests them. A lot of time is spent scratching an itch they have. Some of the things that I saw there were about having more information coming back upstream, not just into the chat rooms, but into JIRA where more of the longer-term tracking is going on. They’re experimenting a lot with putting more information into JIRA.

Miller: Nice. Final question, if you were going to be a superhero, would it be Dev, Sec or Ops?

Buchanan: I’ve played Dev roles and Ops roles and I almost feel like I know those much more. But from a lot of the sessions at DevNexus, I have to feel like Sec is the superhero. They’re the superheroes because they solve some unsolvable problems in a lot of ways. But I don’t feel ready to play that role at the moment, myself.

Miller: It’s interesting. I agree with you that they are unsung heroes. Most of the time they just get hammered for what they’re doing.

Buchanan: That’s true. Yesterday I was in a session about securing REST endpoints. The speaker went through problems with BASIC off , DIGEST off and J2EE—all of these things which we use in our products. At the end we’re left with, “What is the answer?”

Well, the answer is that for each of these, there are different problems. So we have to identify the right context. We have to understand where some things are broken, know that those things aren’t perfect, and design for that imperfection. That’s a mindset that we have to carry through dev, ops and sec. I hope more security folks step up and start telling those stories.

May 6, 2016