devopsy.kinsta.cloud

Tag: SaaS

The Internet of APIs
The Internet moves at the speed of light. Not only that, but the terminology used when describing The Internet seems to change with the tides. One of the newest phrases to start making the rounds is “The Internet of APIs.” In an attempt to understand exactly what it is, I went looking for a definition and was unable to find anything at all. As such, it’s time to put a definition out there.

There are two important words in the phrase: “Internet” and “API”. Let’s start with the last word first and work backwards. What exactly is an API? Luckily, the definition of API is pretty settled. For our purposes, I like the definition given to us by API Evangelist:

An API, or Application Programming Interface, at its most fundamental level, is how software applications talk to each other using the Internet. An API allows you to open up data and other digital resources, to public developers, businesses, or even between departments and locations within a company. APIs are increasingly the way in which companies exchange data, services and complex resources, both internally, externally with partners, and openly with the public.

And while we’re at it, let’s look at the popular definition of “Internet” given to us by Webopedia:

The Internet is a global network connecting millions of computers. More than 100 countries are linked into exchanges of data, news and opinions.

So we’re narrowing down on a definition of The Internet of APIs. But we’re not quite there yet. Let’s look back at recent history to see if we can clarify things a little bit. The modern-day web API has been around since Salesforce introduced it’s API at the turn of the century. In the year 2000, they introduced an XML-based API that kicked off the web services API era. And while there were a few other web services APIs that came out afterwards (including eBay and AWS); but things didn’t really start getting serious until Flickr launched their API in 2004. The social network revolution, sparked by companies like Friendster, MySpace and Twitter, brought about a real need to securely exchange information between multiple applications. So when Facebook and Twitter announced their own APIs in 2006, that was when the usage of APIs grew to include identity management in addition to the exchange of data it had become known for.

And then came smartphones. APIs exploded in popularity once the smartphone industry took over the continent thanks to Palm and Blackberry; then came iOS and Android. Why the popularity explosion? Well, applications needed to be made for these new (popular) form factors. However, these new form factors had very specific requirements around data usage, drastically different screen sizes than application developers were traditionally used to, along with previously unseen device capabilities. Add to that the fact that mobile applications needed to figure out a way to share data with each other securely and a perfect storm of needs presented itself.

While all of this was going on, the wireless capabilities available to the consumer also changed. In the year 1999, one year before Salesforce released their web services API, 802.11a and 802.11b hit the market. WiFi was still a growing technology, but the introduction of 802.11a and 802.11b changed everything. The prior iteration of 802.11 had a transfer rate of 2 Mbps; while a allowed for short range speed of 54 Mbps and b allowed for longer range speed of 11 Mbps. The cost of b was also a lot lower than a.

Also in 1999, the first full Internet service available on a phone was launched in Japan by NTT Docomo. This was during the days of 2G networks. In the US, around the same time, cell phones became affordable to everyday consumers. It was a time of incredible growth in the wireless industry and over the following years, cellular networks were stretched to their limits.

This is the environment that led to the growth of the web service API. There were a few things that were extremely important to the upcoming boom:
1. A speed boost in wireless networking was required; and
2. Wireless networking hardware needed to get into the hands of more people; and
3. The cost of wireless networking hardware needed to drop; and
4. Cell phones needed to get in the hands of more consumers; and
5. Internet service needed to hit the cell phone.
Add all of that to the growth of social networking and identity management via API, and a perfect storm of circumstances presented themselves. More and more APIs were built utilizing a person’s identity for personalization and security.

Thus the Internet of APIs was born.

So, based off of the existing definitions as well as recent history, what exactly is “The Internet of APIs”? The Internet of APIs is:

A global network of structured data, digital resources and commands accessible via a growing interface that allows applications and devices to exchange information using any and all communications protocols available.

Since the creation of the ARPANET (arguably, the Internet’s predecessor) packet-switching networks have been utilized as an efficient and reliable way to exchange data. So what’s different about the Internet of APIs since at its core it’s about exchanging data? The main difference lies in the fact that the data provided by the Internet of APIs is data with structure. It’s data that is being shifted around and meant to be consumed in ways that may not possibly have even been foreseen by the creator(s) of the data. The Internet of APIs allows data that may have been designed for one thing to be used for something completely different; thus facilitating the connection of two completely different applications in ways sometimes unimagined.

The Internet of APIs is the underlying foundation to the Internet of Things. Without the capability for connected devices to personalize their usage according to the individual, as well as share data, the Internet of Things could not exist. Without the improvements in specifications in both wireless and cellular hardware, the Internet of Things could not exist.

The Internet of Things is powered by the Internet of APIs; and as the Internet of APIs grows in scope and capability, the same will happen to the Internet of Things. Without regularly updated data and personalization, a hardware device is dumb. A thermostat is just a thermostat without the underlying API. But with the API, a thermostat becomes a Nest. Without an API, a light bulb is just a light bulb. But with the API, a light bulb becomes a Philips Hue light bulb. Without the Internet of APIs, a person walks in to their home, walks in to their living room, flicks a light switch and turns their heat up. With the Internet of APIs, a person walks in to a warm, well lit home because their thermostat turned on five minutes before they got home and their lights turned on one minute before they walked through the door.

Data and personalization: that is the power of the Internet of APIs.

About the Author/Kurt Collins

Kurt Collins is Director of Evangelism at built.io (link). Before that, he started his engineering career as an intern at Silicon Graphics (SGI) where he worked on debugging different parts of their UNIX-flavored operating system. Two years ago, Kurt co-founded The Hidden Genius Project along with eight other individuals after they all saw the screaming need to increase the amount of Black men in the technology industry. Mentoring young people interested in the technology industry is a personal passion of his. Today, he continues his work with tech startups and non-profits alike.
February 9, 2015
DevOps in Action: MYOB

This is the first in a new series called DevOps in Action. A look at organizations who are putting DevOps into practice. Does your organization have experience putting DevOps into action that you think our readers might find useful or interesting? If so contact us at editor@devops.com and perhaps we can feature your story here.

Australia-based MYOB is a long-established developer of accounting systems and related software. During the last several years its original focus on desktop software has changed, and it now offers cloud-enabled and pure SaaS products. This change had two significant impacts on the company.

Firstly, it meant that instead of simply delivering packaged software to customers, MYOB now has to manage the infrastructure that its SaaS products run on.

Secondly, the traditional annual update cycle primarily driven by tax and compliance issues goes out of the window in a SaaS world, where the norm is continuous improvement based on customer feedback.

“Traditional operations management just doesn’t keep pace with that,” said MYOB business division product delivery manager John Sullivan. “The pace of change has changed dramatically.”

Not only are there more ideas for improvements and new features, but the changes are increasingly “externally fuelled,” he said. This makes it difficult to plan infrastructure requirements very far ahead.

MYOB joined the DevOps movement as it was seen as a way of releasing better software more quickly, and of ensuring that the hardware could be scaled to meet the demands of new software releases.

At some companies, DevOps is about building infrastructure for developers to use, or having operations build infrastructure in parallel with software development, he said.

But MYOB now has operations staff that literally work alongside developers to translate features requirements into infrastructure requirements, and then use repeatable methods to build that infrastructure.

“We scale our infrastructure at the time features are being built,” said Sullivan.

The company uses multiple cloud providers, reflecting the varying needs of its 40-plus products. AccountRight Live (a desktop program that stores its data in the cloud) was written using .NET, so it made sense to use Azure for the cloud element.

And it has adopted a microservices architecture so a single implementation of a function can be used by multiple products (read more about this in ‘MYOB moving ahead with microservices’ http://www.itwire.com/business-it-news/accounting-software/65878-myob-moving-ahead-with-microservices). These microservices mostly run on Amazon Web Services.

Everything else runs on virtual cloud infrastructure provided by Macquarie Telecom.

Using these larger providers means MYOB can be confident that the physical resources are available whenever they are needed, without having to invest large amounts of money in private infrastructure. Having the infrastructure “come alive” at the moment any particular piece of software goes live provides significant savings.

MYOB had an important advantage when starting its DevOps journey: the need for operations staff was new, as it was going from being a traditional software vendor to also offering SaaS products. Sullivan said that made it easier to put development and operations staff together than it would be for an organisation that has a history of managing its own infrastructure, especially with a steady release cadence as opposed to the rapid tempo associated with cloud services.

“We were very lucky that we needed to manage infrastructure for the first time,” he said.

But there were some cultural issues, particularly around making the delivery teams understand they had to take infrastructure into account when building features, as it is important that the cost of delivering the service is kept within reasonable limits. So developers need to tap into operational expertise to ensure that the patterns they use will scale adequately, and that the hooks for monitoring and managing the software are included.

MYOB started with an independent DevOps team with an oversight role, but this was less than optimal, Sullivan said. “If you say you have a ‘DevOps team,’ you probably haven’t” because the closer that development and operations staff are, the better the systems become – getting the right design means looking at application features from several different angles.

Those on the operations side need to be able to advise developers about the software patterns and tools that will be able to handle increasing load. Not only does that potentially avoid the need to build complex failover arrangements, it also saves you running into a situation where you have to re-architect the whole system when demand reaches a certain level. “That’s the advantage of having operations and development people close together.”

MYOB uses the Agile methodology, and infrastructure concerns and requirements are included on feature cards so the software and infrastructure can be built together. As the company gets better at DevOps, developers become increasingly aware of infrastructure requirements and so they build as they go – “we’re just about there with one of our teams.”

“You need operations people with the mindset of a developer … or you’re going to struggle,” he said. For example, you want systems that can automatically scale on demand, and that requires scriptable deployment processes: “a difficult thing to do at times.” Fortunately for MYOB, the company was able to find the right people. It can be hard for development staff to adapt to DevOps, Sullivan suggested, but it’s even harder for traditional operations staff.

One of the ‘tricks’ used by MYOB to build the DevOps culture was to rotate developers into operations roles after the software they had been working on entered production in order to learn about operational requirements. “Then they actually feel the pain of phone calls in the middle of the night if something goes wrong.”

Another is that the company favours ‘self-reflective teams’ (regardless of function) that review what has or has not worked for them during the last two weeks, and adapt their practices accordingly. DevOps is just one area where this practice is used. Sullivan notes that because the environment is so dynamic, ideas are not rejected permanently. So teams can decide that just because a certain technique or idea did not work on a previous project, it might be successful this time because the situation is different in a relevant way.

Early in the transition MYOB filled some key roles with DevOps practitioners that had Azure and AWS experience. But Sullivan warned “there are very few conferences or training courses on DevOps … so most companies don’t do DevOps correctly.” Consequently, special care is needed when hiring people that claim experience in the field.

“The term ‘DevOps’ is overused and sometimes misunderstood.” So some people say they have DevOps experience when all they really know about is doing scripted builds, and do not have the skills and practices to be embedded in a DevOps team.

“There are few people that have the right mindset,” said Sullivan, so it is very important to check a candidate’s skill set against your requirements – and on the flip side, to take the steps necessary to retain your good DevOps staff.

So did MYOB get what it wanted from DevOps?

One initial goal was to go from the traditional software-only annual release to a six-week ‘software and infrastructure’ cycle. “We met that pretty quickly,” said Sullivan, and the company is now targeting ‘any time’ releases for online services with minimal or no interruption. This will allow the company to pick and choose which new features are to be released and when according to marketing priorities, rather than being hamstrung by arbitrary release cycles.

The other was to achieve “one click deployment,” that is to be able to release code and infrastructure to customers with no manual tasks beyond initiating the process. The automated process should either run to completion, or back itself out if something goes wrong. This has been achieved for most products, the main exception being those for mobile devices because the requirements of the various app stores get in the way.

“Other companies may have different metrics, but ours were about release capability and infrastructure efficiency,” said Sullivan.

Asked if MYOB had any regrets about going down the DevOps route, the answer was succinct: “None whatsoever.”

And his advice for others considering following this path sounds sensible for any part of working life. “Embrace the idea that you have to grow and learn, and keep making the best decisions you can at every step.”

About the Author:

Stephen Withers is one of Australia¹s most experienced IT journalists, covering everything from gadgets to enterprise systems. In previous lives he has been an academic, a systems programmer, an IT support manager, and an online services manager. Stephen holds an honours degree in Management Sciences, a PhD in Industrial and Business Studies, and is a senior member of the Australian Computer Society. You can see his Linkedin profile here: http://au.linkedin.com/pub/stephen-withers/0/222/687/

December 10, 2014
DevOps Adoption – Startups

This is part 1 of a 2 part article

DevOps is somewhat unique in that it has applications to both large enterprises and to startups. The way DevOps is adopted in startups is incredibly different than how it happens in large organizations. The profile of how DevOps is adopted in each of these cases is the focus for this two part article series.

In this first installment, we will study how DevOps is adopted within startups and in the second, how enterprises adopt DevOps. There are lessons for each in the way that DevOps is adopted. Organizations can leverage this information to enable better, faster, and easier adoption of DevOps.

Much of the DevOps way is rooted in startup culture. From methodologies such as Agile, lean principles, and just in time manufacturing, startups adopted DevOps as a means to compete, innovate, and move faster. DevOps is inherently a quicker, better way to get product to market – a perfect fit for startups. They could adjust quickly, iterate again and again to get to the point where customers en masse were interested in their technology.

In order to understand how DevOps is adopted in startups, we need to look at how startups evolve. In the high-tech world, a startup gets going when a founder or group of founders has an epiphany for a new product or service. Generally one of the founders will start to develop the solution by writing some code. The startup may add a couple of developers but it is usually just a few folks cranking out the first version of the product. There is often a business or product focused function where requirements and feedback are gathered from potential users or customers.

In this first phase, the development team often adopts Agile as a way to quickly iterate on the development process. These short-term sprints build the initial functionality of the product. While initially, there isn’t really much to release to potential customers, the core developers are starting to build their development and release cadence. The short sprint help to keep the functionality requirements small and the team on-track to deliver a small piece of functionality in a short amount of time. This foundation also ends up being an important part of the future development process. And, just as importantly becomes the kernel of DevOps.

As a small team building the initial releases of the product, the culture and environment of the startup is generally fast, highly communicative with little to no process. Often the development team is sitting side-by-side cranking out code quickly. No specs, just a list of what needs to be done often stored in Pivotal Tracker or some similar tool. Sometimes mockups and screens designed to describe the functionality. There isn’t a rigorous process in the choice of technology platforms – language, database, etc. are chosen often based on what the core team knows or thinks is the right solution rather than on research. This small, agile environment is critical to understand when thinking about how DevOps is adopted.

There is little formal process at most startups. Things are evolving and moving so quickly that there just isn’t time. The goal, after all, is to get a product into market and start selling. While startups are high adopters of Agile as a development methodology, there is generally little rigor in its implementation. There doesn’t need to be because the team is so small and trying to move quickly. Adding in product management, sales, and marketing functions are often ad hoc. There isn’t a well-developed end-to-end product release process. The movement from development to operations is also less than well defined. Often, the developers building the product are the operations people deploying and managing the product or service. Process gives way to the practicality of just getting things done.

The first phases of DevOps adoption start to occur at this early stage in a company’s life. Developers as they are building their product often encounter some basic challenges and begin to solve these issues. How they solve them often dictates whether they take a DevOps path or not. One of the first things that developers do is build an environment to test their software. Often, they will find a cloud provider and start spinning up a few instances to host their application. They also may need a database server to round out their testing. They might manually do this a few times, but as they test more and potentially on different platforms they will start to look for some tools to automate this process. Of course, at this stage, there are likely zero operations people, so the tasks fall on the developers. And, developers wanting to spend more time coding pick-up some tools to do this work.

The tools might include infrastructure providers like AWS, Rackspace, or SoftLayer to configuration automation tools such as Chef or Puppet. There may be a variety of other toolsets chosen as well including project management tracking, libraries, language frameworks, and others. The goal with this first wave of tools is just to save time. That could be by not having to code basic functions, the setup of test environments, or manually tracking tasks. As the organization launches and brings their product or service to market, they may adopt some management and monitoring tools to help them gain visibility into their product or service. Generally at this early stage the decisions are focused on driving short-term problem solving. A developer needs a test environment quickly and repeatedly. A solution to that need is quickly found and implemented. The underlying paradigm is to move fast, solve problems, and get to market.

While tools are hardly a complete DevOps methodology, they are the catalyst for the next step in a startup’s journey to adopt DevOps. Many of the tools chosen in this first period have APIs, can create automation, and are highly configurable. As a startup keeps moving forward and increasing their users, the flexibility of these tools and the various ways that the developers utilize them starts to drive some conversation around process. A few hiccups in the production environment with some bugs, outages, or failures, and the technical leaders begin to start to say the ‘p’ word. Process. While there may be some Agile components already embedded, the growth of the startup starts to create a desire to add in some control, accountability, and guard rails around the product development process. Many organizations will also start to loop in the business side so that there is a more comprehensive process around releasing a product to market. Agile now starts to extend up and down the organization in a more rigorous way. DevOps is starting to take hold and become more fully formed.

The early stage DevOps lifecycle wraps up with it becoming a part of the culture. The organization now shifts into a mode where this methodology becomes a fundamental underpinning of the business. Values such as agility, intense customer focus, rapid iteration and others are a part of the fabric of the company and encompass the entire organization. Hiring decisions are made based on whether the candidates match the philosophy and culture of the company. DevOps is viewed as more than just a process that the company follows, but a competitive advantage in fulfilling its mission to its stakeholders. At this point, DevOps is firmly embedded into the organization and becomes its way of life.

Startups are unique in their approach to adoption of technology and methodologies because of their size, focus, and evolution. DevOps adoption, as we have seen out in the wild, seems to go through some natural stages. While the stages may overlap, it generally follows a tools, process, and then culture sequence. It could be said that some startups just start with the culture of DevOps, and that can be true for some, but many that we see are often so small at that stage that the culture is largely undefined. IT leaders who understand this sequence can become more intentional about the way that DevOps is adopted, perhaps accelerating it or even shaping it earlier in the company’s lifecycle. A little bit from now, our hypothesis is that startups won’t even start without DevOps embedded into their plan.

In part 2 of this series, we will examine the adoption of DevOps at larger companies.

March 27, 2014
The Automation Continuum
The speed of innovation these days is often influenced by the speed of adoption of new and exciting tools, and specifically open source tools. Open source projects have been growing at an exponential speed over the course of the past few years; however the process for exploring, testing, configuring, and ultimately integrating these in production often times is still quite complex and time consuming. In many cases, this process is still done manually. Like with all DevOps processes by automating this, we are then able to adopt new tooling much more quickly, and with less human error in the process.

The Open Source Revolution

The friction in this process is due, in large part, to the fact that each of these stages from exploration through POC and testing, integration and then management, many times requires the use of very different tools for each stage, on top of a completely different setup and environment. This means that every time you want to move from exploration to testing, for example, you have to basically rebuild the entire system. This can become quite frustrating and, as mentioned above, time consuming.

What if we could streamline this process and explore tens and even hundreds of projects quickly, thereby enabling us to seamlessly increase our innovation?

How this could work – the flow:
1. Exploration: Explore the product without having to install any software at all. This could be through a click of a button on Github, and seeing the product in action. This would enable you to play with it without having to download, configure, or set up any machines.
2. Testing: When we move to trying it out, we want to use the same model as in the exploration phase. We’d like to try it out also on a SaaS basis, but this time with more control. By this I mean testing with real clusters & machines, in a more high performance, and production-like environment.
3. Development: At this stage, we want to be able to test it with our actual stack, and plug it into our project quickly. Then, eventually at a later stage download it and run it in our own environment.
What’s Needed

With a unified tool for all of these stages, the majority of the friction in the process can be diminished. One way to achieve this is by running the project as a service or in our environment, with an orchestration engine that can basically be used to take us through all these stages.

By wrapping the entire project into an uber-launcher [which with Cloudify we call it “the widget”] that any open source project can plug into – like an app store or repository, and any user can start using immediately without necessarily having to know how exactly it runs or works.

The nice thing is that we can eventually take the software from that app catalog or store, since it’s not packaged as a black box but rather as a blueprint or script. We can then fork it and customize it to our needs. Because of this, we can actually use the same tools through the entire cycle and break the friction completely.

So what it all boils down to, is the basic principle of combining the power of SaaS and cloud orchestration to avoid complexity of installation, use a script-based model to make the packaging of software generic – but still customizable, and use a cloud abstraction to move environments without having to change recipe. This is what we call the automation continuum, and we’ve been using to demonstrate how to take the power of any open source project to any cloud.
March 25, 2014
Ops is dead, long live DevOps

Yes, that’s a bold statement, but if the vibe at the recent AWS re:Invent conference was any indication there are a number of methodologies, technologies, and companies working to make that a reality. This article isn’t focused on whether this is a good or bad thing (my personal belief is that ops will always be a critical part of the IT delivery process). Regardless, it is critical for IT operations personnel to understand the implications of this tectonic shift. As Marc Andreessen, founder of the venture capital firm Andreessen Horowitz, has said, “software is eating the world.” As a result, ops professionals must have the ability to automate tasks that used to be managed manually. Whether or not you think that is the death of ops as we know it I will leave to you, but it does mean we will live in a world where DevOps will offer distinct advantages.

Before we dive into what this change means to ops personnel, let’s review the underlying assumptions. The fundamental driver at the a high level has been the DevOps movement. Yes, DevOps is quickly becoming the buzzword dejour, but the underlying principles are lasting and changing IT to its core. DevOps is about integrating the various functions that it takes to release software or applications: software development, quality assurance, operations, and security among many others and rapid iteration. The process of integrating these tasks is accomplished through new processes and automation. Different functional areas such as development and operations are brought into the process earlier, and their processes are automated to the extent that they can be. This results in fast cycle times, increased quality, and hopefully increased innovation for the business. All of this is accomplished through software – at each functional level.

Some technologies that have enabled this massive shift include Infrastructure as a Service (IaaS), Platform as a Service (PaaS), automated configuration management, server management tools, virtualization, and software defined networking. IaaS and PaaS offerings are eliminating the need for organizations to procure, provision, and deploy servers. Further, this class of technology is also dramatically reducing the need to deal with the network layer. This allows organizations to concentrate on their applications and development, and focus less on their infrastructure. The amount of time and effort spent on server and network configuration is minimized. Configuration management solutions are enabling the automation of server setup. An organization’s technology stack can be pushed, pulled, cloned and copied versus manual configuration thereby saving time and adding consistency. Top performing organizations employing DevOps go a step further and automate the scaling of capacity based on utilization. To reduce day-to-day operational activities and costs, organizations are also automating the management of servers, including users access, patches, security, and other areas through both traditional written code and SaaS solutions. Another area changing the game for ops personnel is software defined networking (SDN), which is effectively morphing data center and hardware functions into software programs.

In short, DevOps and associated innovative new technologies are driving a paradigm shift in the way operations is done. No longer are ops personnel required to manually provision, configure, and manage the network, servers, and application stack. Combining technologies from organizations such as AWS, Rackspace, and SoftLayer along with configuration tools such as Chef and Puppet drives the provisioning and configuration of applications through software automation rather than manual effort. Once applications are deployed, the underlying infrastructure can be managed with tools such as my own company, New Relic, this author’s own JumpCloud, and others. Ops personnel have more companies than ever focusing on helping them automate the tasks that they need to deliver applications for their organizations.

The result from all of this effort is that ops as we know it won’t exist in the future. The network operations wizard that could manually troubleshoot routing and switching issues, provision servers quickly, and tweak configurations will be tasked with automating those tasks through software. Some of that automation will be through code that ops person writes herself, some delivered by third party providers, and other portions delivered by open source or SaaS-based solutions. But, don’t shed tears for the forced obsolescence of the IT ops people. They will still exist and perhaps be more important and powerful than ever. In fact, because of DevOps ops personnel will in essence be set free from mundane, repetitive “busy work” to perform higher value tasks as well as managing over the software and systems at work. The black magic of enabling different layers of the stack to function together will be less about art and more about science, or rather good software. Solutions will be engineered to work together and be tied together through code. Caveat: yes, service providers and some large enterprises will still run their own data centers and networks, but the same reasons that DevOps works in IaaS or PaaS will apply to private data centers or private clouds as well.

If all of this trends toward being true as we see it happening today, what are the opportunities for ops personnel to be at the forefront of this shift? Beyond embracing DevOps – which many operations personnel are doing already – learning to code is the most critical step that ops professionals can take. Many ops professionals already know how to script which is absolutely a minimum, but many will need to go further. Embrace the DevOps movement and push further towards the development side by learning how to code. There are any number of amazing services to teach us how to code or code better. Take the step. It may be the difference between a vestige of the old school versus driving the new world in your organization. The second significant step you can take is to automate your job. Leverage the very best automation tools to code your network, server, and application infrastructure. Not only will you spend less time on these tasks manually, but you will increase availability, reliability, and performance. In most organizations, that’s more than a gold star. Finally, make the mental shift that operations in the future will be less art and more science. DevOps is driving action through data, and the technology stack is responding to this demand with more telemetry than ever. Problems are now solved through understanding performance, availability, and other metrics. And code.

DevOps is the future. Automation is key. Code is the answer. Developers and ops are in it together for the good of their organizations. Ops pros that embrace this will win! Ops is Dead, Long Live DevOps!

March 12, 2014