How I explained dynamic cloud to my kids by Stewart Hyman
How I explained dynamic cloud to my kids by Stewart Hyman, Certified IT Architect and an IBM Master Inventor
"Daddy, what do you do?”
Ugh, there’s that dreaded question again.
Honestly, there are days I wish I’d gone into medicine, teaching or even astrophysics, if only so I could more easily explain what I do. My saving grace is that kids today understand more about computers than I do; my seven and eight year olds can easily pick up concepts that even I sometimes struggle with.
Dynamic cloudIt was simple for them to pick up the concepts of outsourcing, managed services, process choreography and even cloud computing. We use cloud storage services to share pictures with family and friends around the world, so the concepts were in no way foreign. But when I started explaining how I design cloud solutions for large companies and started delving into the concept of composable services and dynamic cloud, it made me pause and try to think in terms they could understand.
It quickly dawned on me that this struggle to understand dynamic cloud is one that only really plagues adults, that it was my struggle (yet again) and not theirs. Adults tend to live with more rigid rules, consuming pre-built services from pre-built systems, and generally have very few options to choose from. But kids are urged to use their imagination and instead build fit for purpose solutions out of numerous different building blocks. For example, LEGO has 2200 different types of pieces, so if you compare the scope of options that kids deal with compared to adults it becomes easy to frame dynamic cloud in terms kids will understand.
Here’s how I explained it:
Dynamic cloud services are like LEGO blocks, each with their own features and costs. Some blocks are bigger and simpler while other blocks are smaller and more complex, but each block serves a specific purpose. At IBM we have been creating managed services “blocks” to provide different capabilities on top of servers, like backup and restore, storage tiering, patching or anti-virus scanning. We can sell these blocks separately and they can be integrated into existing or newly-built capabilities in our company. Luckily IBM has been doing services management for years, so we have a lot of existing capabilities we are wrapping into blocks. We also have a lot of smart people who are working on building newer and better blocks that are more automated or have lower cost.
You only pay for the blocks you use while you use them, and when you are done you throw the block back into the bin and stop paying for it. This part is extremely important because it provides a mechanism for customers to save a lot of money on things they aren’t using. In existing managed services you usually sign two to ten year contracts that overestimate how much you have to spend or how much you need to use. Dynamic cloud gets rid of this problem by allowing you to only pay for the services you use. In order to do this, the system has to be capable of automatically turning on and off services you want. This is no small order because many of these services existed before cloud, so updating them to be automated and to fit into this dynamic new world requires heavy thought and redesign.
You can save money by using cheaper blocks or leaving blocks out entirely. This was never an option in a traditional outsourcing contract; we would use fixed teams, tools and services for all servers at all times. These services cost what they cost and you were paying a standard high price service fee whether you needed those services on each server or not. In dynamic cloud, this is no longer the case. You could dynamically tailor the services per server, allowing a whole new paradigm of flexibility and cost reduction options. Perhaps you might use disaster recovery services on production servers but leave them off development servers. Maybe you’d use file level backups on production servers and full system image backups on test servers, but no backups at all on development servers. Any given service might cost the same or more than it actually did before dynamic cloud (backup and restore likely will not be cheaper now than it used to be), but the combined costs and features can be tailored greatly to suit your specific need per server, and therefore you can be confident that costs always align with your use case.
Some people use Krazy Glue to lock blocks together in a pattern, so they act like a single compound block. Sometimes blocks work better together when combined in a specific way and can offer features or costs savings that only apply when combined in that way, so we create a pattern to remind us of that special combination. Until now patterns have really only focused on infrastructure configurations (servers, storage, networks, operating systems and more) or application configurations (application nodes, platform per node, applications and so on), but dynamic cloud can introduce the concept of service patterns to this as well (groups of services that should be combined together for best practice, or to achieve new compound service levels or cost reduction).
Dynamic cloud with service composition patterns
Anyone must be able to contribute new building blocks and patterns. If you make the mistake of centralizing the development of building blocks in a “closed” development model, then you run the risk of creating bottlenecks and limiting community contribution or adoption of the model. There are a lot of people out there with skills, time and money to contribute, and you have to enable them rather than stifle them or try to control them. Linux is a great example of an open approach to community contribution fostering more rapid growth and adoption. It allows the entire enterprise to start contributing and allows for distributed projects to prioritize and fund their own additions. It even allows other vendors or customers to contribute as well.
But they have to comply with certain standards. Even LEGO blocks have standard connectors with standard measurements, so any new block must comply with these standards in order to be useable and helpful and snap on easily. The same is true for dynamic cloud; a framework is required to make sure everyone is developing assets in a common, reusable, best practice-oriented way, with good documentation and so on. Examples are easy to find. Each service needs to be billed, be presented from a single “store front” for purchase, define standard service level agreements (SLAs), present owner and contact details and so on. You don’t want to bill customers 100 different ways if they use 100 different services. You don’t want the customers to look in 100 places to find the services. They need to know who to contact if a service breaks. You need to centralize and standardize certain features and define clear guidelines for contribution, but once you do this you effectively allow a community of experts, each in their own area, to begin adding capabilities to the mix and grow together.
After listening intently to all this, my boys seemed excited, so I was sure I’d gotten through until almost in unison they said: “Daddy, now I understand what you do! Can you buy me some new LEGO?“
You can’t win them all.