There is nothing worse than going home for the holidays and having a family member ask you to fix their computer, or WiFi, or smartphone, or Facebook account. It’s not that the issues are that complicated, they often aren’t, but it’s the pre-repair stories that you have to hear about what they didn’t do (“nothing changed”), what they didn’t click on (“Aunt Millie sends funny pictures”), or what they expect the computer to automagically do for them. And for that reason, many people assume that a role in Technical Support is 8×5 of your families complaints over a long holiday weekend.
In reality, technical support is a great place to break into the IT industry. This guidance applies to people interested in computers, hardware, software, infrastructure or application development. My first “real” technical job was in Technical Support, at Cisco, many years ago, and I still believe it gave me the foundational skills that I’ve needed for almost every other job I’ve had in the tech industry.
So why am I bringing up technical support? This past week I had the opportunity to speak with a young woman named Tanya Selvog, who has been working her way into the technology industry through a series of training courses and self-driven initiatives. Her goal is to become a programmer/developer, but she mentioned that she’s often given the guidance that she should go into technical support first, as a way to get her foot in the door at technical companies.
I can understand the hesitation to move into technical support roles. The perception is that you’re on the phone all day, taking questions from people that are upset about their current situation (e.g. computers are broken) and you’re going to get the brunt of their frustration. Or the flip side is to believe that you’re role would quickly be replaced by an automated bot or some other “intelligent system” that would allow self-service for the customer. To some extent, both of those concerns are valid and true.
But the other reality is that technical support is going to force you to learn a technology, or several technologies, really in-depth. You not only have to know how the technologies work, but you also have to know how they behave when they are broken or misconfigured or misused. This allows you to expand your ability to not only learn, but become a creative problem solver. Both of these skills are foundational for any role in technology. Technical support roles also force you to put yourself in the end-users shoes and understand the challenges of technology from their perspective. This forces you to have compassion and empathy for people that don’t get to go to training classes or have extra time to keep up with all the latest rumblings on Hacker News. It also gives you the opportunity to take the self-guided initiative to figure out ways to make problems go away on a broader scale. Maybe that means developing a new tool that customers can easily download to fix a problem, or make sure a problem doesn’t happen in the first place.
The bottomline is that technical support can be a great role to learn technology, learn people skills and learn how to proactively help scale your knowledge. I’ve seen plenty of people that started in the IT industry in tech support roles (at vendors, at customers, as independent contracts) and go on to much bigger roles over time because they could blend all those skills together.
Technical support isn’t for everyone, but if you’re trying to break into the industry and your first path is bumpier than expected, maybe give it a try for a year or two. The cloud is going to need a whole new set of people, with modern skills, that are going to need to keep all those devices working as expected – both for businesses and for in-laws.
As more IT organizations adopt open source technologies, it’s useful to understand that community releases are somewhat different than proprietary software from a single vendor. Let’s take a look at the most recent release of the popular Kubernetes project, version 1.8.
What’s Included with Kubernetes?
Last week on PodCTL (@PodCTL) we discussed a topic that often comes up with companies that want to build a DIY platform using Kubernetes. How much is included in the Kubernetes open source project, and how many other things have to be integrated to create a functional platform for deploying applications into production?
- What’s included?
- What’s not included?
- How to manage integrations.
- What standards exist to make it simpler?
- What’s the difference between DIY, a Kubernetes distribution, a Kubernetes platform, or a Kubernetes cloud service?
Anatomy of a Release
The first thing you’ll probably notice that’s different between OSS and proprietary “releases” is that OSS often contains individual features marked as “alpha” or “beta’. In the Kubernetes 1.8 release, they are broken down between alpha, beta and “stable”. These relate to the levels of maturity of each feature, as determined by the project’s steering committee. Since OSS project software is DIY support, via mailing lists, Slack groups, IRC, etc., it’s up to companies to decide if they want to enable certain features.
If companies decide to use a commercial offering based on OSS, or a public cloud service based on OSS, then it’s important to understand what they will fully support vs. make available as “alpha or beta” support.
For example, from Google’s GKE service:
Who Built the Features?
Often times, after a release is published, people will attempt to analyze who developed certain features. Some vendors publish blogs highlighting their involvement (e.g. here, here, here). Other vendors highlight projects that add value outside the core project, as they focus more on training or services. You can always dig into the details through sites like Stackalytics or GitHub. You can also dig into the details of individual features or functional areas by reading the notes from the Special Interest Groups (SIG).
There are lots of opinions on how to interpret stats around OSS commits. Some believe they include too much vanity, or can be gamed. Others believe that they are a good indicator of how much an individual company (or person) is investing in a project, and how much they could help customers that want official support of an OSS project.
Updates Come More Frequently
The last thing to keep in mind is that OSS releases tend to come out much more frequently that proprietary releases. In the case of Kubernetes, it’s consistently been every 3 months. This means that if a company is running the software (vs. using a public cloud service), they need to make sure they are prepared to stay up-to-date with infrastructure/platform updates. They need to have skills around CI/CD and config management tools like Ansible, Chef, Puppet. . This is a skill that development teams have been evolving for the past few years, but it’s a skill that operations teams will have to improve quickly.
Usually I use this blog to write about new technologies or technology trends. But as I’ve been out on the road lately, I’ve had quite a few people ask me about how to get started in podcasting. There are lots of podcasts out there these days, covering nearly every topic. I co-host a couple weekly podcasts (The Cloudcast, and PodCTL) that are regularly in the iTunes Top 100 for technology, so I suppose I have some scars and experiences that can be shared with others. Here are the some the most common tips I’d give anybody that wants to create a technology podcast.
btw – here are some great tips from the company that I host my podcasts with (Buzzsprout)
We’ll get into more details later, but here are the basics of every successful podcast:
- Be interesting. People are potentially going to give you some of their valuable time, and allow you to be right in their ears, so don’t waste that opportunity.
- Be consistent. If people like your content, they want to know when it’ll be available. It’s difficult to do, but focus very hard on being consistent in producing new content. The goal should probably be weekly, and around the same time each week.
- Be “listen-able”. In a digital world, it’s very simple. People won’t waste their time on good/great content if the audio quality is bad. Be willing to invest in good microphones and some basic editing tools. It only costs a few hundred dollars and will often be the #1 or #2 factor in if you create a following.
Beyond those basics, here are some other things to consider.
Figure out why you want a podcast.
When we got started with The Cloudcast, our goal was to find way to learn about the fast moving technologies that were being created in Silicon Valley. We lived in Raleigh, NC and didn’t have immediate access to the people making it happen, so we decided that we needed a way to facilitate that learning. Our basis premise was that we wanted to learn and those people might be interested in having their knowledge broadcast on the Internet. It was a win-win scenario.
So for some people, the ability to have technical conversations is the motivation for having a show. For other people, maybe it’s the need to get better at “public” speaking. Still others may want to use it as a marketing vehicle for their company, using this growing new medium.
Pick a topic that you’re passionate about.
If your goal is to create the show on a regular basis, make sure to pick a topic or area that you’re passionate about. You have to bring energy to the discussion, otherwise your listeners won’t give you their time and attention.
And consider a topic/area that has some range, because otherwise you might find yourself out of things to talk about after just a few episodes.
Consider the format – scheduling is difficult.
Some shows are two people, just talking. Other shows have more co-hosts or bring on guests. The general rule of thumb is that the more people included, the more complicated it will be to schedule the show. It also makes the dynamic of the on-air conversation more difficult, as you don’t have the normal “visual clues” that you get with face-to-face topics.
With regard to scheduling, the best advice I can give is to pick a regular block of time that you’ll record and stick to it as much as possible. This aligns to Tip #2 (above) about consistency. If you have a fixed time to record, it makes it easier for your to coordinate your schedule and it simplifies the scheduling with co-hosts and guests. People have busy schedules and the last thing you need is 10-12 emails floating around about times when people “might” be available.
Another consideration for format is that most technology podcasts are either “educational” or “entertainment”, with the majority being the former. What this means is that you probably need to spend less time giving opinions and more time either not talking (let the guests speak) or focusing on educating in a non-biased way.
Spend some time on the audio quality
There are two pieces to the audio quality:
- The actual quality of the sound.
- The quality of the conversation, from the perspective of speech “tics” (e.g. umms, ahh, you knows, rights, etc.).
The quality of the sound is fairly easy to address these days. There are lots of lists of the best podcasting microphones, most of which can be acquired for a few hundred dollars. A couple things to consider:
- Will I be recording at a known location (e.g. your house/apartment) or will you want to be mobile in how you record?
- Get the “pop” filter to go in front of the microphone.
- Get a basic stand for the microphone so you can direct the angle at which you speak into it.
- If you use a table-top stand, get a shock mount to avoid the noise created when you nervously tap on the table while you’re talking.
It seems obvious, but try to record in a quiet location. It also helps it the location lacks echo, which can be minimized with things like rugs, furniture, curtains or other noise-cancelling mechanisms.
Regarding the quality of the actual content, this is ultimately a time vs. quality tradeoff. In 99.99% of the shows, you’re going to have people that have the normal human ticks in their speech. These will range from occasionally to consistently annoying. When it comes time to publishing the show, you have to decide how much time you’re willing to edit these out (or reduce them). It can often take 1-2hrs per 30mins to do this sort of editing. In general, I’d suggest not spending much time reduce the nature conversation, unless it was impactful to getting any useful information out of the show.
When it comes to recording, there are two models that most people use:
- Record it themselves, using something like Skype, Google Hangouts or one of the many conference services (Zoom, Bluejeans, WebEx, Highfive, etc.). We typically use Skype, just because we always have and it’s fairly ubiquitous, and we record with a tool called Audio Hijack Pro. There are lots of recording tools out there. Just be sure that you can natively record from the app/service being used, and I highly recommend recording in AIFF format for higher fidelity. Using AIFF also comes in handy when editing.
- Use a 3rd-party service for podcast recordings like Zencastr. It costs some money, but it takes out lots of hassles for you (trade off time vs. money). Plus people can record directly from the web.
Now, if you decide to record it yourself, there are two tools that I highly recommend. Audacity is a very good tool for editing and mixing audio tracks. For example, you might want to add in music/intro/outro tracks to the beginning and end of shows. Levelator is a great tool to make sure that all the audio on the show is at the sound sound level. This avoid someone talking too loud vs. too softly. NOTE: Leverator only works with a few audio formats, hence why I mentioned recording in AIFF earlier. If you have to record in MP3, then use Audacity to transcode it to AIFF for you.
..and finally, Publishing
I’m sure there are advanced strategies for publishing, but we tend to live by one simple rule. Publish it everywhere you can afford, because you never know where your audience will be.
- Use one of the podcast publishers like Buzzsprout or Libsyn. They will store the files for you and give you an RSS feed. They usually charge a monthly fee based on how many hours of content you produce.
- Add the RSS feed to the major distributors – iTunes, Google Play, Stitcher, TuneIn, SoundCloud. NOTE: Some of these will distribute for free, while others have a monthly charge. Still others like Spotify have a filtering process and aren’t easy to gain access to their network.
- Let people know where they can find your show through various social media channels, word-of-mouth or any other marketing channel you have access to.
The open source world is different than the proprietary world in that there really aren’t formalized standards bodies (e.g. IEEE, IETF, W3C, etc.). That world is mostly defacto standards, with some governance provided by foundations like The Linux Foundation, Cloud Native Computing Foundation, Apache Foundation and several others.
Container Standards – Migrating to OCI
In the world of containers, there have been many implementations for customers to choose from over the past 5-7 years. On the container side, there was native Linux capabilities like cgroups and namespaces, and then simplified implementations like LXC, docker, rkt, appc, runc. A couple years ago, a new group was formed (the Open Container Initiative – OCI) to try and unified around a common container format and runtime. It took a couple years, but the OCI has finally come out with OCI 1.0. We discussed those details with one of the project leads, Vincent Batts from Red Hat. We dug into the list of requirements, and how they created a standard that works across Windows, Linux and Solaris operating systems.
Container Orchestration Standards – Kubernetes is Leading the Pack
Around the same time that OCI was getting started, several options were emerging for container orchestration. The PaaS platforms had all created their own homegrown orchestrators several years before. But maintaining your own orchestrator is a very difficult engineering task. The game changed when some of the web scale companies, specifically Google and Twitter, released implementations of their internal systems (Kubernetes and Mesos, respectively) into the open source communities. In addition, Docker created the Swarm orchestrator for the docker container format/runtime.
For several years, companies and customers made investments around each of these standards. Dozens of comparative charts were made, trying to position one vs. the others. But over time, more and more developers started focusing their efforts on Kubernetes. By the current count, Kubernetes now has 4-5x as many developers as all the other projects combined. Early adopters like Google, Red Hat and CoreOS jumped into the Kubernetes project, and recently almost every major vendor has gotten in line. From VMware to Microsoft to Oracle to IBM, and a list of startups such as Heptio, Distelli, and many others.
One important thing to note about Kubernetes is that CRI-O, the Container Runtime Implementation for OCI, is now the default. In the past, the docker runtime was the default, but now Kubernetes is allow more standard options to be used. Google’s Kelsey Hightower has an excellent write-up, as well as making it part of his “Kubernetes the Hard Way” tutorial.
And beyond Kubernetes, we’re also seeing the most popular ecosystem projects being focused on Kubernetes first. From monitoring projects like Prometheus, to application service-mesh projects like Istio and Linkerd. As CNCF CTO Chris Aniszczyk recently said, “CNCF is becoming the hub of enterprise tech.”
Around this time every year, prior to VMware’s VMworld conference, I write a predictions post. Here’s a few from past years – here, here, here, here, here. This year I decided to change up the format and record it as an audio podcast – The Cloudcast #308 – Can VMware cross the Cloud chasm? – with some of the smartest people in the industry covering VMware, virtualization, software-defined-infrastructure and hybrid cloud. Keith Townsend (@ctoadvisor) and Stu Miniman (@stu) will be hosting theCUBE all week at VMworld, and have covered the event for the last 5-7 years.
Here is some of their pre-show coverage:
- Keith’s preview of VMworld 2017
- Wikibon’s VMworld preview including video with Stu and Dave Vellante?
It was a great discussion that covered updates on the Dell/EMC/VMware merger; the evolution of VMworld’s ecosystem vs. public cloud providers like AWS, elephants in the room and the HCI market.
- Topic 1 – What’s new in your world and what trends are on your radar these days?
- Topic 2 – A couple weeks ago The Register forecasted that VMworld is a shrinking event and a stark contrast to the growth of AWS re:Invent. From your perspective, what’s the state of the VMware ecosystem these days?
- Topic 3 – With Dell being private but VMware is still public, and their stock being up about 2.5x since the merger ($40-100), is there any sense of how money is flowing within VMware (e.g. R&D) vs. flowing over to pay Dell’s debts?
- Topic 4 – You both get access to the VMware executive team during the week of VMworld. What questions do you wish you could ask them, but it’s not appropriate during the interview or Q&A formats that exist?
- Topic 5 – Can you explain VMware’s “Cloud Strategy” to us?
- Topic 6 – HCI (HyperConverged Infrastructure) is growing very quickly and all the vendors now have an HCI play (Nutanix, DellEMC VxRail, HPE Simplivity/Nimble, Cisco SpringPath, Red Hat HCI, etc.). Does the market need this many similar offerings? Which one of these is non-existent in 3-4 years?
For the last 6+ years, I’ve hosted a weekly podcast called The Cloudcast (@thecloudcastnet), which focuses on all aspects of cloud computing. One of the challenges of having a broad focus is that you rarely ever get to dig deeply into a specific topic. And when that topic is growing extremely fast (e.g. Kubernetes), it can be frustrating spend so little time understanding the technical and business elements.
A year ago, the buzz around “serverless” or functions-as-a-service was growing so loud that we kicked off The ServerlessCast (@serverlesscast) shows. Those allowed us to go in-depth on many topics around serverless.
For the last 2+ years, the rise of containers and container orchestration has grown tremendously fast, with open source projects like docker and Kubernetes gaining market share and attracting 1000s of developers. So once again, we’re spawning off another new podcast to dig into this technology in-depth. The show is called PodCTL (@podctl), and it can be found as on RSS Feeds, iTunes, Google Play, Stitcher and all your favorite podcast players. This weekly show will come in two flavors – the PodCTL shows and the PodCTL “Basics” shows. The PodCTL will go in-depth on technical topics, interview with thought-leaders and developers, as well as review the news of the week and areas for learning the technology. The “Basics” shows will be a short, ~ 10min introduction to core technology areas, and will be suited to beginners or business leaders looking to better understand this space.
The first 3 shows are now available:
- PodCTL #1 – 3.6 Ways to Love Kubernetes
- PodCTL #2 – Who has a Kubernetes problem?
- PodCTL Basics – What is Kubernetes?
Each show is filled with show notes that provide links to all the information discuss each week, such as news stories, training, new technology announcements, etc.
Feedback to the show is always welcomed. If you enjoy the show, please subscribe, tell a friend or give it a rating/review on your favorite podcast network.
What aspect of DevOps poses the biggest challenge for IT leaders? As I discussed DevOps with hundreds of leaders during a recent event series with Gene Kim, an author of The DevOps Handbook, I heard one answer loud and clear: It’s the culture change. The concepts of blended or shared responsibilities, blameless postmortems, and speed vs. stability often run counter to the principles you’ve been taught about leading IT. You realize that the future of the business will be highly impacted by your ability to deliver software faster (via new features, new products, and new routes-to-market) – but you struggle to find a language or framework to communicate to your teams (and peers) about how to make DevOps and these results happen.
Far too often, we ask IT leaders to learn the language of lean manufacturing or the principles taught by W. Edward Deming. While these approaches are valuable, and can draw a parallel between the factories of physical goods and 21st-century bits factories, they require yet another learning curve before change can occur and take hold in an organization.
So with that in mind, I thought it would be useful to adapt a popular business framework, Steven Covey’s “The 7 Habits of Highly Effective People”, into a model that can be used by business leaders trying to bring DevOps culture into their organizations. Let’s see if this can help solve your language struggle.
1. Be proactive
Let’s start with the one constant in IT: Change happens, constantly. If you started 20 years ago, client-server was just beginning to gain momentum. If you started 10 years ago, the iPhone had barely been introduced and AWS had 2 services. If you started 5 years ago, Linux containers were still overly complicated to use and web-scale companies weren’t open sourcing important frameworks.
We’ve seen massive changes over the last 50 years regarding which companies lead their respective industries, and which market segments are the most valuable (hint: today it’s technology). Business leaders must recognize that technology is driving these changes, at a more rapid pace than ever before and be proactive at being prepared for the next round(s) of changes. Be the change agent that the business requires. Be responsible for behavior, results, and growth.
2. Begin with the end in mind
No business executive wakes up and says, “We have a DevOps problem!” Instead, you lose sleep over reducing time-to-market for new capabilities, reducing security risks, and other metrics that can be directly tied to the top or bottom line. This is why I believe that “Confidence in Shipping Software into Production” is the most important DevOps metric.
At its core, this metric begins with the end in mind: Can we get software into production safely and reliably? From there, you work backwards to determine how frequently this can happen, which leads to an examination of existing skills (people), ability to manage deployment frequency (culture), and if the right tools and platforms are in place (technology). Focus your time and energy on things that can be controlled.
3. Put first things first
You need to execute on the most important business priorities. While it’s easy to imagine what a greenfield organization would do to make “DevOps” the default technology culture, the reality is that this is not an immediate reality for most organizations. Their org charts are optimized for yesterday’s business model and distribution strategy. They have many application platforms, often siloed for different lines of business. And they need to adapt their applications to become mobile-native in order to address emerging customer expectations.
Putting first things first, these core elements need to be in place before the business can expect to be successful at rapidly deploying software into production.
- Automation – It is critical to build core competency in the skills and tools needed to automate repetitive tasks, both for applications and infrastructure. For many companies, it’s valuable to begin with a focus on existing applications (both Linux and Windows) and infrastructure (e.g. networking, storage, DHCP/DNS), and then evolve to automating new applications and services.
- CI/CD Pipelines – Just as factories (since the early 1900s) have been built around assembly lines, building modern software is driven by automated pipelines that integrate source code repositories, automated testing, code analysis, and security analysis. Building skills to manage pipelines and the process around frequent software updates is critical for building a framework to manage frequently updated software applications.
- Application Platform – Once applications have been built, they need to be deployed into production. In today’s world, customers expect to get updates to their software on a frequent basis (e.g. mobile app updates each week), so it’s important to have a repetitive way to deploy application updates and scale to meet the business demands on the application. Managing the day-to-day activities of applications is the role of an application platform. For many years, companies tried to build and maintain their own application platforms, but that approach is rapidly changing as companies realize that their value-add is in the applications, not the platform.
Once these elements are in place, many IT teams are ready to start containerizing their existing and modern applications.
4. Think win-win
Far too often, the DevOps discussion is framed as the tension and disconnect between Development and Operations teams. I often call it an “impedance mismatch” between the speed that developers can push new code and the speed that operators can accept the updates and make sure that production environments are ready.
Before we blame all the problems on operations being too slow, it’s important to look at why it’s believed that developers are so fast. From the 2017 State of DevOps report, we see that Gene Kim (and team) measure the speed at the point when developers push code into source control (e.g. Git, GitHub.)
They aren’t measuring the speed of design and development. Even in a microservices environment, it can take several weeks or months to actually develop the software features.
So how do teams potentially get to a win-win scenario? Here are a few suggestions:
- For Operations teams adopting automation tools and Infrastructure-as-Code principles (e.g. using source control for automation playbooks), both development and operations are beginning to use common practices and process.
- For Development teams, insist that security people are embedded within the development process and code review. Security should not be an end-of-process step, but instead embedded in day-to-day development and testing.
- For both teams, require that automated testing becomes part of normal updates. While many groups preach a “cloud-first” or “mobile-first” policy for new applications, they should also be embracing an “automated-always” policy.
5. Seek first to understand, then be understood
Six or seven years ago, nearly every CIO said that they wanted to try and emulate the output of web scale giants like Google in terms of operational efficiency (1000 servers per 1 engineer) and be more responsive to developers and the business. Unfortunately, at the time, it was difficult to find examples of companies outside of Silicon Valley that could actually execute at a similar level. And the technology Google used was not publicly available. But times have changed significantly over the last few years. Not only is Google’s technology (e.g. Kubernetes) readily available via open source projects, but the examples of enterprise companies implementing similar success are plentiful.
So before you send a few architects out to Silicon Valley to study with the masters, it might be more valuable to study similar companies to your own. This will surfaces experience that are industry-specific, region-specific, and use-case-similar. It will also help answer the question of, “But, how can we do that without hiring 100+ PhD-level engineers, or $1M+ salaried employees?” Sometimes the right answer is to leverage the broad set of engineers working on popular open source projects.
I’ve often said that everything someone needs to be successful in DevOps they learned in first grade. For example, “play nicely with others,” “share,” and “use your manners.” The challenge is that org charts and financial incentives (such as salaries, bonuses, and promotions) are often not aligned between Dev and Ops teams in order to accomplish these basic goals.
Some knowledge of Conway’s Law comes in handy here. If the goal is a specific output (e.g. faster deployment of software into production), make sure that the organizational model is not the top barrier to accomplishing the goal. Cross-pollination of ideas becomes critical. Teams need to share their goals, challenges, and resource availability with other teams. You want to innovate and problem solve with those who have a different point of view.
7. Sharpen the saw
It would be easy to say that IT organizations need to make sure that their teams are keeping up-to-date on training and new skills. But all too often, this becomes a budget line-item that sometimes get ignored. The proper way to address the need for “skills improvement” is not to think about it as “training” (perhaps attend a course, get a certification), but rather to incorporate it into an actual work activity.
We’re moving into an era in IT where all the rules and best practices that have been stable for the last 15 to 20 years are being re-written. This means that it’s critical to leverage modern ways to learn new skills. Encourage employees to seek the best way for them to learn (such as side projects, meetups, and online learning) and then have them bring those new skills back to the rest of the team. Make it a KPI to improve the skill levels and skill diversity of the entire team, with incentives for individuals and the overall team to get better. Bottom line: Seek continuous improvement and renewal professionally and personally.
The importance of storytelling
The 7 Habits framework has proven to be successful in helping individuals and groups improve interpersonal skills. Those skills are at the core of any cultural transformation.
Beyond the 7 habits, one more skill should be on every leader’s mind. One of the most important skills that IT leaders can leverage as they drive transformation is the ability to tell stories of success and change. The storytelling skill can inspire emotions and can help spread successes from group to group. Storytelling also helps a group to personalize its challenges, and adapt solutions to suit the group’s particular cultural nuances.
Microsoft’s journey over the past 3-4 years, since the appointment of CEO Satya Nadella, has been a fascinating example of how large companies transform. Like many established IT vendors (e.g. Oracle, Cisco, HPE, EMC, NetApp, etc.), the challenge of adapting to a world that is more software-centric, more cloud-centric, and includes heavy doses of open source software has been a difficult challenge. It requires rethinking almost every aspect of the business, and making some difficult short-term decisions.
One of the first things that Nadella did was abandon former CEO Steve Ballmer’s three-pronged plan to move Microsoft into devices and services. This meant that they needed to move away from the massive Nokia acquisition, and move away from the mobile phone business which is dominated by Apple and the Android ecosystem). It’s unusual for a new CEO make such a significant shift from the prior CEO, especially before they had built up significant credibility with Board of Directors and Wall Street.
During the 80s and 90s, Microsoft was almost entirely defined an Operating System company, defining and dominating the growth of the PC market. But since 2000, with the massive expansion of the Internet, the relevance of a desktop PC has become less and less important. I’ve written before that Microsoft would be smart to think about how to be less focused on the Operating System and more focused on application developers. The rise of the smartphone and the decline of the PC has defined the past decade of computing. And unfortunately, Microsoft missed the opportunity for the smartphone OS. Windows is no longer a valid OS for smartphones.
While it took Microsoft a little while to adapt and encourage their largest revenue base (Microsoft Office Suite) to move to the cloud and be delivered as a SaaS offering, the growth of Office365 now appears to be strong. This allows Microsoft to continue to have the cash-cow business that drives the rest of their investment.
And that brings us to Microsoft’s public cloud strategy – both Azure and AzureStack. When it was originally designed, Microsoft Azure was focused on PaaS (Platform-as-a-Service), while AWS focused on core IaaS (Infrastructure-as-a-Service). Microsoft expected to leverage their large base of .NET developers, but the offering was the wrong time and had the wrong services. They fell behind AWS. But over time, the Azure cloud has refocused on a broader set of service (IaaS, PaaS, Big Data, non-Windows workloads) and has begun to grow quite large. By most accounts, it’s now the #2 public cloud provider. The next big step will be to break out the Azure revenues independently.
Recently, Microsoft took yet another step in their cloud journey. A step that many existing IT vendors have struggled with. They laid off a number of their existing sales teams, with a refocus on how to specifically sell to a base of customers that want to buy from the cloud. They also signaled at their Inspire conference that they plan to start paying their sales teams, and partner sales teams, based on consumption instead of just purchase volume. This will be a very interesting move to watch, as this will require a completely new approach by sales teams. Instead of just selling large ELAs (Enterprise License Agreements), which could result in shelf-ware, they will be forced to be more in-tune with actual customer usage. It will also create some interesting scenarios where they may encourage customers to use more resources than they actually need, in order to drive their own compensation. In addition, it will force customer to begin learning how to budget for IT consumption in an on-demand world – something they’ve never had to do before. For many companies, this has proven to be extremely difficult.
History has shown us that the leaders from one era of technology rarely remain the leaders into the next era. Microsoft is trying to make that transition, so it will be interesting to watch how well some of the significant changes are accepted, and where their competition is able to maneuver around them without their legacy baggage.
Over the past few weeks, I’ve had the great privilege to partner on a series of roadshows with Gene Kim (@realgenekim) author of “The Phoenix Project”, “The DevOps Handbook” and the annual “State of DevOps Report”. The events are called “Culture, Containers and accelerating DevOps, the path to Digital Transformation” and they provide us with an opportunity to speak with developers, enterprise architects, IT operations engineers and business executives about how they are implementing technology and culture changes to help them deliver software faster into their markets.
During Gene’s presentation, he highlights a series of lessons that he’s learned since writing The Phoenix Project. Some of these include:
- The Business Value of DevOps is higher than expected.
- DevOps is as Good for Ops, as it is for Devs.
- The Importance of Measuring Code Deployment Lead Times.
- The Surprising Implications of Conway’s Law. (organizational structure)
- DevOps is for the Unicorns, and the Horses too.
The lessons are supported by a series of stories, examples and data from businesses that Gene has interacted with over the past 4-5 years, as they navigate their DevOps journey.
What’s the Most Important DevOps Metric?
At some point in every event, someone from the audience will ask the question, “If you had to boil it down to a single thing, what is the most important DevOps metric for us to track?” Gene’s answer is often the topic #3 (above), focused on measuring code lead times. It comes from his experience studying the Toyota Production System and it’s approach to flows-of-work, managing and correcting defects, and empowering employees to make the on-going changes needed to improve production of the end product. In essence, he highlights that today’s data centers have become 21st-century bits factories, with the goal of producing high-quality, agile software applications.
For the most part, I’d agree with Gene that this is an important metric to track. But with all due respect to his expertise in this area, I actually believe that there is a better metric to track. And Gene actually calls out this concept in his talk: An Organization’s Confidence Level of Shipping Software into Production.
In my opinion, this concept is more appropriate than any specific metric, because it forces the technology team to think about their actions in business terms. It also allows them to have a conversation with the business leaders in a way that is focused on impact to customers. It directly aligns to every company becoming a software company, and the importance of making software “go to market” becoming a core competency of the business.
It allows the technology team to begin with the end in mind, and work backwards from the goal of safely shipping software into production. Their level of confidence in the end goal will also force them to consider why their current confidence level may not be the highest it could possibly be.
- Are we investing (people, technology, partnerships) for success towards the goal?
- Are we designing our software, our systems and our platforms to handle the emerging needs of the business?
- Are we enabling a culture and set of systems that allow us to learn from our mistakes, and make improvements when needed?
When I think about this concept, I’m encouraged by the level of confidence from John Rzeszotarski – SVP, Director of Continuous Delivery and Feedback – at KeyBank.
John talked about the DevOps journey at KeyBank and how they focused on culture, continuous integration pipelines, automation, containers and their container-application deployment platform . This was a 12-18 month journey, but where they are today is pretty remarkable. He summed up his talk by telling a story about how they recently re-launched services from one of the banks they had acquired. The highlight was that they were able to deploy 10 new updates to the production application, with 0 defects, during the middle of the day. That is a very high level of confidence in shipping software into production, and in the elements that make up their DevOps culture.
The KeyBank story is a great example of making a significant impact to the business, and measuring the technology in terms of business success and agility.
NOTE: Below are my slides from the Culture, Containers and Accelerating DevOps roadshows.
This week, I was listening to an episode of the “Speaking in Tech” podcast and the guest was talking about why he believed that container usage may be overhyped and not necessary a good thing to be exposed to developers or operators.
When having these types of discussions, I believe it’s important to look at not just the evolution of container technology, but the evolution of container platforms. From this, we have learned a few valuable lessons:
Give Developers Flexibility
Whether we’re talking about PaaS (Platform as a Service) or CaaS (Containers as a Service) technologies, the end goals are fairly similar – make it simpler for developers to get their software into production in a faster, more stable, more secure way. And as much as possible, hide/abstract away much of the complexity to make that happen.
Early PaaS platforms got part of this equation correct by delivering Heroku-like “push” functionality to developers. Have code, push code, run code. But they also got part of the equation wrong, or at least limited the developer experience too much. In other words, the experience was too opinionated. The early platforms limited which languages could be used by developers. They also forced developers down a path that limited the versions or variants of a language that they could use.
By letting developers to use standards-based containers as a packaging mechanism, it allowed them more flexibility than the original PaaS platforms allowed. It allowed for more experimentation, as well as letting developers validate functionality using local resources (e.g. their laptop).
Align Technology and Culture
The guest on Speaking In Tech was correct in saying that no single technology, nor a single culture shift, will give a company a technology advantage in the market. It requires a mix of technology evolution and cultural evolution, geared towards delivering better software for their business. Containers plays a role in this. As container can be the unit of packaging and unit of operations, it begins to create a common language and set of processes for both Developers and Operators. It’s not everything, but it’s a starting point. It needs to be augmented with expertise around automated testing, automated deployments and the CI/CD pipeline tools (e.g. Jenkins) that allow for the consistent movement of software from developer to QA to production, and the on-going operation of that software. By hiding the visibility of containers from either developers or operators, it requires more effort to find commonality between the evolving technology and culture.
Container Platforms Have Quickly Evolved
As container usage grows, we’re learning quite a bit about making them work successfully in production. At the core of that learning is the maturity of the underlying container platforms and how to manage them. The reality is that successful container platforms are a combination of the simplicity of PaaS and the flexibility of CaaS. They allow developers to push code, binary images and containers into the platform (directly or via CI/CD integrations) and they give operators a stable, multi-cloud platform to run those applications. We’ve seen the number of developers working on platforms like Kubernetes grow significantly, and businesses are adopting it around the world. And with the evolution of Kubernetes Federation, we’ll begin to see even greater adoption of truly hybrid and multi-cloud environments for businesses.
Containers have experienced a meteoric rise in interest from developers over the last few years. It’s enabling greater flexibility for developers, it’s bringing together developer and operations teams with common technology, and it’s enabling multi-cloud deployments which are expanding interactions between companies and their marketplaces.