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.
For the last few weeks, I’ve been traveling quite a bit, so I’ve spent a decent amount of time on airplanes. When airplane WiFi is poor (quite frequently), so pass the time watching movies. For me, I’ve been watching the excellent “Long Strange Trip” documentary on Amazon Prime, about the history of the Grateful Dead. If you like music, or history, or just enjoy good storytelling, I highly recommend the series.
Coming up on my 1yr anniversary of working at Red Hat, it struck me how many parallels there are between the evolution of the Dead and how open source software communities [LSD trips and being under the constant influence of drugs excluded]. The Grateful Dead have often been characterized as “a tribe of contrarians who made art out of open-ended chaos”. They phrase could easily apply to many open source communities.
[Episode 1] Committed to Constant Change
The Grateful Dead are known as being a touring band, not one that spent time focused on commercial success via studio albums. Like open source software, their music was constantly evolving, and it was interpreted differently by nearly everyone that saw them perform live. As they began to slow in their contributions, their model was “forked” and replicated by touring bands like Phish and Widespread Panic. Similarly, open source software is less about a single project than a style of development and collaboration that is constantly evolving and the principles being copied (and evolved) by many other projects.
[Episode 2] Finding Success on Their Own Terms
While the record labels wanted them to conform to their recording and sales models that were used by most other bands, the Grateful Dead decided to adopt alternative business models. At the time, selling albums would have been more profitable, but they were actually ahead of their time in focusing on live events and allowing their music to be fragmented and easily copied (bootleg tapes). Similarly, many analysts would like to see open source companies deriving revenues in similar ways to proprietary companies, but that model hasn’t been fruitful. Successful open source companies have adopted support models and SaaS models to drive revenues and success.
[Episode 3] Let’s Join the Band
While the Grateful Dead had 5 or 6 original members, the documentary highlights how Donna and Keith Godchaux “just decided to learn the music and join the band” in 1971. Random fans of the Dead actually joined the band and stayed with them for many years. This is not unlike how anyone can join an open source project just by showing interest and making a meaningful contribution.
[Episode 4] Who’s In Charge Here?
For many people, the connection between Linus Torvalds and the Linux project is the model that they expect all open source projects to have. They expect a BDFL (Benevolent Dictator for Life). In most projects, the BDFL role doesn’t really exist. There might be strong leaders, but they realize that broader success needs many leaders and tribes to emerge. This same dichotomy emerged for Grateful Dead, where Jerry Garcia was the visible leader, but he didn’t want to set all the rules for how the band (or their audience) needed to behave.
[Episode 4] and [Episode 5] I’ve yet to see these episode yet (the next airplane flights), but looking at the previews, they appear to have similar open source parallels. They focus on the growing success of the band and how people set higher expectations than the band wanted to take on themselves. This can often happen with successful projects, where commercial expectations begin to drift from core community expectations. This is where strong leadership is needed just as much as the early days of the project.
If you’re interested in open source software, or some insight into how communities ebb and flow, I highly recommend this documentary. And the music is obviously great too.
This past week, Walmart issues a statement to their retail partners, suggesting that they should not run their technology stack on the AWS cloud. This is not an unprecedented move for Walmart, who has required that their partners have a physical presence in Bentonville, AR (Walmart HQ) for many years, in order to simplify meetings and reduce travel costs for Walmart.
It’s understandable that Walmart wants to keep valuable information about their business trends and details about their partners away from AWS (and indirectly, Amazon). This is not to imply (in any way) that customer data is collected by AWS, but there is no way to determine how much meta-information that AWS can collect about usage patterns that could influence the services they offer.
What’s interesting about this statement from Walmart is that they don’t offer a Walmart-branded hosted cloud alternative to AWS. This brings up an interesting dilemma –  Does this create a unique opportunity for the Azure cloud or Google cloud?,  Does Walmart have concerns about Google’s alternative businesses (e.g. Alphabet) collecting data patterns about their partners?,  Will Walmart partners be swayed by this edict, especially given Amazon’s growing market share in retail?  Will this force Walmart to get into the hosted cloud business? Do they keep enough cash on their balance sheet to compete in that market?
Back in December, I predicted that the Trump administration would pick a fight with Amazon, as proxy for Jeff Bezos’ ownership of the Washington Post. That hasn’t materialized yet, although the year is only half way complete.
This action by Walmart ultimately brings up the question: Can non-traditional tech companies begin to impact AWS in ways that traditional tech companies have been unable to do – e.g. slow down AWS growth? The reach of companies such as HPE haven’t been able to slow it down, but maybe Walmart’s massive reach can have a different impact on the market. It will be interesting to see if Walmart reports this in their quarterly reports, or begins to make this a public issue with their Office of the CTO.
Beyond Amazon vs. Walmart, this bring up yet another interesting question – Will we see existing companies with large ecosystems or supply-chains (e.g. automotive, healthcare, etc. ) apply cloud guidance to their partners (e.g. must use XYZ cloud), or has the world of APIs completely changed what a modern supply-chain now looks like? The concepts of “community clouds” have never really taken off in practice.
This past week, we did some reflection on The Cloudcast about the evolution of technology over the last 6+ years. One of the topics were discussed was the impact that OpenStack had on the industry. People has various (strong) opinions about the level of success that OpenStack has achieved, but we discussed how OpenStack changed the IT landscape in a number of significant ways.
Announced and launched in 2010, OpenStack was designed to deliver an API-driven cloud infrastructure, similar to AWS EC2 compute and S3 storage. At the time, there was a split about whether the project(s) would focus on being a VMware replacement, or an open version of AWS services. This was heavily debated by groups focused on both agendas.
Software Defined Infrastructure
While OpenStack was by no means the first implementation of infrastructure services (networking, storage, firewall, proxy, etc), it was the first significant time when this approach to technology was embraced by Enterprise-centric vendors. Until then, both Enterprise-vendors continued to provide hardware-centric offerings that complimented offerings like VMware virtualization. Since then, API-centric infrastructure is becoming more commonplace in the Enterprise, especially with the emergence of containers and container platforms.
Open Source in the Enterprise
While companies like Red Hat, SUSE and Canonical had been selling commercial open source to the Enterprise for many years, OpenStack was the first time that companies like Cisco, HPE, NetApp, EMC and many others were attempting to combine proprietary and open source software into their go-to-market offerings. Since then more IT vendors have been building open source offerings, or partnering with open source centric companies to bring offerings to market for customers that are demanding open-first with their software.
Who’s in Charge of OpenStack?
While Rackspace may have wanted to leverage all the engineering talent to take on AWS, it wasn’t able to maintain ownership of the project. The OpenStack foundation was an early attempt at trying to bring together many competing vendor interests under a single governance model. Critics would argue that it may have tried to take on too many use-cases (e.g. PaaS, Big Data, DBaaS) and projects in the early days, but the project has continued to evolve and many large cloud environments (Enterprise, Telco) are running on OpenStack.
Since the creation of the OpenStack Foundation, several other highly visible open source projects have created independent foundations to manage the governance of the projects (e.g. CNCF, Cloud Foundry, etc.)
Founders Don’t Always Make the Big Bucks
While OpenStack was viewed as a disruptive threat to the $1T Enterprise infrastructure industry, and heavily funded by venture capital, most of the founding individuals didn’t make out in a big way financially. Piston Cloud and Cloudscaling were sold to Cisco and EMC, respectively, with relatively small exits. SwiftStack has pivoted from just supporting OpenStack to also supporting multiple public cloud storage APIs and software-defined storage use-cases. Nebula went bankrupt. Even Mirantis has moved their focus over to Kubernetes and containers. Ironically, Red Hat has become the Red Hat of OpenStack.