Are we rowing backwards from public cloud?

For the last few years the mantra has been the same: “cloud is the destination”, by which we assume public cloud.  The economics are obvious; why would organisations choose to maintain their own fixed cost data centres when they could use someone else’s facility and only pay for what they use?

For startups and smaller organisations who had no technical legacy to worry about, or who ran mainly on SaaS offerings, this was great – they could remove those servers lurking under desks or in cupboards.  However for most of the customers I deal with (i.e. large corporate enterprises) it wasn’t this simple.

Colocation

Back in 2014 there were confident predictions that over 80% of enterprise workloads would be running in public cloud within 5 years.  3 years later, and only a handful of those workloads have made the switch, and for the most part that’s been ‘lift and shift’ – moving from VMWare on-premise to VMWare in the cloud, for example.  Enterprise customers aren’t seeing the often-promised flexibility and performance improvements which come from true refactoring of applications for cloud – their code is just too complex.

But it’s not just the code that’s a problem.  There is a reluctance on the part of many business leaders to commit to ‘letting go’ of their data.  I’ve heard it said that this is about mindset and perception (after all, pretty much every major data breach has been from a customer’s own data centre).  However there are often challenging legislative and regulatory reasons why this may be the case.

In the EU, for example, data about EU citizens has to stay within the European Economic Area, unless the country it is sent to can maintain an “adequate level of protection”.  What does that mean?  How do you prove it?  What controls do you have over the nationality of data centre employees in third party countries?

Yet enterprises want the flexibility that cloud brings just as much as anyone else – after all, their survival could depend on it.  New disruptors with no technical debt are using cloud-native technology to take customers from the incumbents.

And so we’re seeing a subtle shift – new offerings bringing the benefits of cloud, but in the customer’s own data centre – not just VMWare, but containers, Cloud Foundry, even serverless compute platforms, all designed to run on kit which the customer already has.

In June IBM announced IBM Cloud Private, a software-based IaaS and PaaS platform combining Kubernetes (for containers) and Terraform (for VMWare).  It’s aimed squarely at those customers who run their business with Java Enterprise applications, and who want to migrate to more cloud-like technologies in their own space.  Microsoft has Azure Stack, for customers coming from a .NET world.

No surprises there – IBM and Microsoft have always been big in the enterprise space.  What’s interesting is that Google have teamed up with Pivotal and VMWare to bring their flavour of containers to an on-premise audience, and even AWS have acknowledged that customers may still want to use their own servers.

The end of the private data centre will happen, one day.  But that day may just be a little further off now, as enterprises are given more options for flexible deployment behind their own firewall.  When legislation catches up with technology, or encryption improves, that may change, but it’s still a long way off.

Advertisements

Blockchain and the third trust revolution

Blockchain has the potential to sweep away the central trust authorities of governments, banks and corporations as  I discussed in my previous post.

Why? Because blockchain enables virtual communities to re-create the person-to-person trust of small villages and societies at a global scale.

Ancient societies were based on the idea of personal trust: I trust you because I know what you have done. I know the moral and ethical code by which you live.

Blockchain cannot enable people to know a person they have never met, but they can see what that person has done in the community network. Users know the business code which by they live, because it’s encoded into the blockchain as smart contracts.

It’s person-to-person trust at a global scale.

blockchain-trust-3

For example, there is a micro-energy grid in New York which lets people with solar panels sell that power directly to consumers using a blockchain. The grid is run for the mutual benefit of the small-scale generators and their customers. There is no utility company in that model.

Blockchain brings providers and consumers together in a mutually beneficial business network, where everyone agrees the rules in advance and plays by them.

If you doubt that blockchain has the potential to be at least as disruptive as the web, consider this: the web has changed how we live our lives with e-commerce, digital banking, streaming music, TV on demand, social media, Yet it has not fundamentally changed the economic models that our world is built on. We still buy music from a music company. We still book taxis from a taxi company or car service. It might be Spotify and Uber now, but they are still central trust authorities.

Imagine if we could connect providers and consumers directly, for the benefit of everyone, not just corporations. If we could connect passengers and drivers, authors and readers, people who want to lend, with people who want to borrow? What would that world be like?

The third revolution

Blockchain is a new type of database. It has key characteristics which enable participants to have a high degree of trust in the data, and the business network. It allows users to take the person-to-person trust of small groups and scale it globally.

Throughout history, we have had to invent new trust mechanisms. The first real trust revolution was coins, and the second was the intangible monetary system.

Blockchain has the potential to be the third trust revolution, sweeping away the monetary system in the same way that that system swept away coins, relegating them to loose change that we use to pay for coffees.

Just as coins and money helped to accelerate global wealth, the applications which blockchain will enable will drive our economy through 21st century and beyond.

Learn more about IBM Blockchain.

(This post originally appeared on IBM’s Cloud Computing blog)

Trust revolutions and the need for blockchain

In my previous post, I outlined what makes blockchain a transformative technology. It builds trust in data and business networks, which makes it the latest part of a long history of trust as the basis for economic transactions.

People trust each other based on personal knowledge. I trust you because I know you and what you have done.

That worked for small groups of people; tribes and ancient villages. If your roof leaks and the rains are coming, I will help you to fix it, because I trust that you will provide some reciprocal help at a future date. Sociologists say this type of favor-based personal trust breaks down once a community has more than about 150 people.

Therefore, throughout history, humanity had to invent new trust mechanisms to scale the economy.

blockchain-trust-2

The first real innovation in trust was coins, first minted around 640 BC in Lydia (modern Turkey). They are a universal mechanism of immediate asset exchange that enable someone to sell and olive crop, take the coins to the local market and buy clothes for their family. Coins have no inherent value, but each person trusts them because everyone else does and they are backed by a central trust authority, in the past a king or emperor, with power derived from the gods. As long as the king and his kingdom stood, the coin had value and citizens could trust it.

Coins enabled accumulation of wealth. There are only so many favors you can accumulate, but there is no limit to the number of coins you can have. This enabled villages to gather wealth and become cities, and it enabled cities to levy taxes to build temples, walls, roads and theaters.

Coins also enabled portability of wealth. A professional soldier in a field in England could take coins back to his family in Greece, for example.

This trust in coins, based on central trust authorities, underpinned the classical world, enabled trading networks such as that of the Phoenicians and helped to build the first great empires: Roman, Persian and Han. Human economic activity then stayed roughly the same for the next 2,000 years.

Around 1500 AD, the ‘new world’ was re-discovered by Europeans, creating a demand for exploration and investment. There was also a wave of religious reformation across Europe, which meant that it became acceptable to make money from money (this had been considered a sin).

To build a ship and sail it across the ocean was incredibly expensive and highly risky. Very few individuals could afford that, but groups of people could fund a share in a ship and take a share of the risk and profits, which was more acceptable. The concept of limited liability companies was born.

Insurers such as Lloyd’s of London offered to spread the risk on those ships and banks started to collect money from small investors, buy up the shares and pass on the returns in smaller (but more reliable) amounts.

The real innovation here was intangible money, money which you cannot see but which will come back to you in the future. You can hold a coin in your hand; you can’t hold a share. You can hold a piece of paper which says ‘share’, but you are ultimately trusting in the limited company, the insurers, the banks and the legislation which underpins that. Lawyers call these “legal fictions.”  They don’t actually exist, yet we put our trust in them anyway.

This concept of a monetary system saw an explosion in the amount of capital available for exploration and trade. It underpinned the great commercial empires like the East India Company and the Hudson’s Bay Company, funded the Industrial Revolution and paved the way for Bretton Woods and the modern economic system we have today.

All of that is based on central trust authorities. But we’ve moved on from kings and gods as the basis for currency, in favor of corporations, banks and governments. That’s why we need blockchain, which I’ll discuss in my next post.

(This post originally appeared on IBM’s Cloud Computing blog)

4 characteristics that set blockchain apart

I speak to lots of customers who are using or thinking of using blockchain.

Depending on who you speak to, blockchain is either a new power poised to change the way we do business or the latest IT hype.

I believe blockchain has characteristics which mark it as something transformative, perhaps even more transformative than the web.

At its core, blockchain is just a database, one that is particularly good at dealing with transactions about assets, whether they’re financial assets, physical assets such as cars, or something more abstract like customer data.

blockchain-trust-1

But blockchain has four key characteristics which make it different:

  1. It is designed to be distributed and synchronized across networks, which makes it ideal for multi-organizational business networks such as supply chains or financial consortia. It also encourages organizations to come out from behind their firewalls and share data.
  1. You can’t just do whatever you want to the data. The types of transactions one can carry out are agreed between participants in advance and stored in the blockchain as “smart contracts,” which helps give confidence that everyone is playing by the rules.
  1. Before one can execute a transaction, there must be agreement between all relevant parties that the transaction is valid. For example, if you’re registering the sale of a cow, that cow must belong to you or you won’t get agreement. This process is known as “consensus” and it helps keep inaccurate or potentially fraudulent transactions out of the database.
  1. Immutability of the data. Once you have agreed on a transaction and recorded it, it can never be changed. You can subsequently record another transaction about that asset to change its state, but you can never hide the original transaction. This gives the idea of provenance of assets, which means that for any asset you can tell where it is, where it’s been and what has happened throughout its life.

Taken together, these four characteristics give organizations a high degree of trust in the data and the business network. That level of trust makes blockchain important for the next generation of business applications.

To understand why, one must understand the nature of trust. To do that, I’m going to take a short detour through 25 centuries of human economic history in my next post.

(This post originally appeared on IBM’s Cloud Computing blog)

Why you need a Cloud Architect

Would you consider rebuilding your house without engaging the services of an architect?  Probably not. They’ve seen countless previous projects similar to yours and they can spot patterns – and advise you on what works and what doesn’t. 

So would you consider migrating your IT infrastructure and applications to ‘the cloud’ without a Cloud Architect?  You would be surprised how many try it. 

To be clear, I’m talking about someone with knowledge across a wide range of cloud patterns. Cloud isn’t just about lift-and-shift of a data centre to virtual servers. Nor is just about OpenStack or Cloud Foundry or SaaS. Cloud is about applying different techniques and strategies appropriately for each situation, in the same way that a building architect uses different physical materials, lighting and texture to produce an end result. 

A good Cloud Architect will advise you on the best approach to take for each part of your IT landscape, whether that’s your legacy mainframe and ERP environment, your test and development suite, or your modern innovation and disruption platform, and will keep this advice grounded in the needs of the business.

Moving to cloud can be an upheaval, but it is also an opportunity if managed correctly. For instance, it could be the perfect chance to try new application patterns, such as microservices and APIs, or to look at new technologies such as cognitive solutions, Internet of Things or Blockchain. It is critical to have someone who understands these approaches and how they fit together, and who can give sensible advice on how to adopt them in your own environment.

So if you’re planning your move to cloud, don’t fall into the trap of thinking that one size fits all – there are many routes to take. Engage a good Cloud Architect and you’re half-way there. 

  

What’s Your Cloud Exit Strategy?

One of the promises of cloud is workload portability; the ability to move workloads seamlessly between on- and off-premise and between different cloud providers. But sometimes, making the wrong architectural choices can hinder that flexibility. If your cloud provider suddenly increases their prices or has technical issues, can you quickly and easily move to another? 
 

Have you taken advantage of the underlying platform? Cloud providers compete not just on price and availability, but on additional features above and beyond the standard VM platform (such as Amazon’s IAM). It can be tempting to build your virtual machines and applications to use these features, but what happens if you want to change provider? Will these features still be available, or will you have to undertake an expensive redevelopment exercise? I met recently with Fedr8, who have a useful code analysis tool which can tell you whether your application will run in a given cloud environment. 

Have you used standard PaaS services? Most PaaS providers will offer backend services such as databases, reporting, monitoring etc, but make sure you choose well-supported options. MongoDb and Redis might be widely available, but if you choose a more esoteric database, you’re potentially limiting your choice of providers.  Of course, this can be a trade-off. If you want to take advantage of IBM’s Watson cognitive computing, for example, you’re going to have to use IBM’s Bluemix.

How easy is it to ‘flick the switch?’ OK, so you’ve decided to move from Amazon to Rackspace. How do you configure that within your own systems? How do you stop users from doing what they’ve always done? The answer lies in a good cloud orchestration platform – a front-end which hides all the complexity from the users. If a developer needs a new dev/test platform, they can have one – it will exist with a new provider, but the user doesn’t need to know, nor should he care. An orchestrator can also manage long-running environments – shutting them down and moving them without disrupting users. 

What about commercials? It may sound obvious, but if you’ve signed a contract with a cloud provider that commits you to future payments, then nothing architectural is going to help you. Be aware of the contract terms you’re signing up to, and try to stay on pay-per-use until you’re sure you’re happy with your provider. 

What happens to ‘dead’ environments? One of the reasons organisations choose to leave a provider is regulatory – a government decides that customer data can only be held in-country, for example. So what happens when you click the ‘delete’ button on a virtual machine? Is the provider contractually responsible for securely destroying that data? If not, then it should definitely be part of your lifecycle management processes. 

In summary, moving from one cloud provider to another should be easy, but can have challenges. A little up-front thinking, combined with a good orchestration platform for governance can go a long way to help. 

Public, Private, Hybrid, SaaS? Dispelling Some Myths

There seems to be much confusion over the various cloud business models, so let’s start by dispelling the biggest myth of all: there is no cloud.  All of your ‘cloud’ applications are running on a real CPU, with real RAM and real hard disk, in a real data centre.

Once you accept that, it becomes easier to understand the models.  Firstly, on-premise and off-premise.  If an application is running on-premise then it’s in your data centre – you are paying for power, cooling, tech support, etc.  If it’s off-premise then it’s running in somebody else’s data centre.

Now we need to consider the deployment and business model – private, public, hybrid or SaaS?

Private cloud means that your workloads are running on a dedicated physical machine.  That could be in your data centre (in which case you probably own the machine), or someone else’s data centre (in which case you’re probably renting it).  That machine could be ‘bare metal’ (i.e. you have to install the operating system, hypervisors and everything else), or it could be pre-loaded with a full cloud stack such as OpenStack.  Whichever deployment you choose, with a private cloud there is no one else on the server.  But it typically costs more.

Public cloud means that your workloads are running on a shared physical server.  Your bit will be isolated in one or more VMs (virtual machines), but you may get issues with ‘noisy neighbours’ hogging the resources of the physical server with their heavy workloads.  Public cloud is always rented – you never own these machines – but like private cloud you can get either ’empty’ VMs or pre-built cloud stacks.  It depends on how much work you want to do in setting up.

Hybrid cloud is a growing phenomenon.  This involves running workloads in a private, on-premise cloud for most of the time, but ‘bursting’ out to an off-premise, public cloud at certain time – to cover peak trading periods, for example, or to cover downtime due to server maintenance in your own data centre.

Note that for private, public and hybrid cloud, you will need to manage the licences for whatever you’re running in those clouds.  You will also almost certainly need some cloud orchestration capability, or you’ll spend a lot of effort on administration and monitoring of your cloud workloads.

Software-as-a-Service (SaaS) is different.  With this model you don’t have to set up a load at all – the software vendor does that.  You pay to use their cloud, and everybody else’s data is in the same cloud as you – just separated by a username and password.  If you’ve used Gmail, or Netflix, or Adobe Creative Cloud – then you’ve used SaaS.  The advantages are that there is no set up time – just create an account and go – and that you don’t have to think about licensing.

Generally, private cloud gives you more control than public or SaaS, but is more expensive and more complex to set up.  Choose the model that best fits each particular workload.