Once again, the pundits are lauding the new year as the Year of the Public Cloud. This seems the equivalent of the emperor’s new clothes. The Year of VDI having gone out of fashion, it is all about EUC now, you know.
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