A few years ago, I told HP’s product manager for public cloud that I thought all public cloud providers would run out of money and get out of the business. I was mostly being controversial to spark conversation. But HP has recently ceased selling its Helion public cloud. While this did prove me right in that case, I’m not sure every public cloud provider will remain unprofitable until it dies. I do think it is very hard to compete with AWS for a commodity public cloud. On the other hand, there are ways to build a public cloud that address clients who will not use AWS.
The container market is moving at the speed of light. Each vendor in this space is delivering features at an amazing pace. In fact, things are moving so fast that this article will likely be way outdated in about 2 months. It was just under two months ago when I reported on the many announcements made at DockerCon 2015 in San Francisco. Since then, each vendor has made a number of significant announcements about new features or partnerships. Here is a rundown of what has been announced by the major players in the hot container space. Continue reading Tracking the Hot Container Market
In this day and age of cloud computing, this article’s headline may come as a bit of a shock to many of you. Yes, the mainframe is still a thing. And IBM’s newest is a beast of a machine, capable of over 2.5 billion transactions a day, with real-time encryption built in.
One of the great advantages of the public cloud is its elasticity, the ability it gives systems to provision and deprovision resources as workloads increase and decrease. Much has been written about how building RESTful services is crucial to deploying elastic services in the cloud. I concur that writing code loosely coupled with the underlying infrastructure and abstracting things like business rules, business processes, and systems configurations into independent modules is a key to elasticity. What I have not seen discussed enough is how we should be abstracting the different types of server farms away from each other to eliminate tightly coupled dependencies between compute resources. Continue reading Designing for Elasticity
There has been a great deal of passionate debate over the last few months within the OpenStack community. There is one camp that is advocating for building APIs that are compatible with Amazon Web Services (AWS) APIs, while the other camp argues for augmenting the existing OpenStack APIs. Those in favor of making the APIs more compatible with AWS are focused on standardization and compatibility between OpenStack and AWS. Standardizing on the AWS APIs makes moving workloads between OpenStack and AWS clouds easier, thus giving OpenStack a competitive advantage over other private cloud stacks. It also makes it easier for customers to move workloads off of AWS (public cloud) to OpenStack (private cloud) for customers wanting to deploy on bare metal machines, keep critical data out of the public cloud, or have the flexibility to target a cloud endpoint based on their customers’ desires (for those delivering solutions to customers outside of their enterprise). Continue reading Moving Past the OpenStack API Debate