The Truth-Machine of Gilly-Goo

The Count of the Wobbleygooks

I help you, you help me, and then we both see, That a world that is fixed is the best place to be. Life is a team sport, we’re all on the field, and the truth is the power that makes the best yield. It isn't just nice, and it isn't just sweet, It's the smartest way possible to stand on your feet.

In the center of town, where the Snaggle-Vines grow, Stands a Great Gilly-Machine, all a-gleam and a-glow! It hummed with a whistle! It whirred with a thump! Producing the Fizz-Juice that makes your heart jump! It puffed out the Puff-Pills! It clinked out the Toys! For all of the Gilly-Goo girls and the boys.

But this Great Gilly-Engine, so shiny and vast, Needs a very specific and special breakfast. It doesn’t eat crackers! It doesn’t eat cheese! It eats Only-True-Things, if you please, if you please! It needs the exact count of Snallywag-Socks, And the "Ground Truth" of pebbles inside of your box.

Young Pip was the Player in charge of the Count, To tell the Machine the exact right amount. He’d count every Wobbleygook, green, blue, and red, Then whisper the number right into its head. "Six Wobbleys today!" he would shout with a grin, And the Fizz-Juice would pour from the spout to the bin.

But one Tuesday morning, while counting the Goo, Pip tripped on his shoelace and dropped a, oops... Two! Two Wobbleygooks tumbled! They rolled down the hill! They splashed in the river and sat very still. Now Pip had a problem. His count was quite wrong. (And the Machine needs the Truth to keep humming its song).

"If I tell the team," Pip thought with a sigh, "They’ll know I’m a stumbler! They’ll know I’m that guy! They’ll pause the whole game, read maintenance books, And give me those 'Oh-Pip-You-Clumsy-Oaf' looks." So he looked at the Engine, and whispered a lie: "The count is still Six!" with a wink of his eye.

He thought he was clever! He thought he was fast! He thought that his "Fiction" would certainly last. He’d saved his own face! He’d stayed on the track! But he’d put a big hole in the team’s Gilly-Goo-Sack...

Dot’s Helpful Drip-Drop

Now Dot was the Player on the very next base, With a Gilly-Goo wrench and a smile on her face. Her job was to polish the Wobbleygook Shells, And ring all the Gilly-Goo Gongs and the Bells. She waited for Six, as the Engine went clink, But she only saw Four... which made young Dot blink.

"That’s funny," said Dot, "Pip whispered for Six, But there’s only these Four for my wrenches to fix! If I tell the team that the count is quite low, The Gilly-Goo Game will be dreadfully slow. Poor Pip will feel silly, his face will turn red, And the 'Team' will have chores and go late to their bed."

So Dot, being 'kind' in a way that was wrong, Decided to help the Machine get along. She took some old Snallywag-Socks from a pile, And stuffed them in Wobbleygook Shells with a smile! She made the Four look like a Six-pack of Goo, By adding some fluff and a little bit of glue.

"There now!" whispered Dot, "I have fixed the mistake! I’ve saved us some time! I have lowered the brake! The team is still winning! The game is still fast! My helpful Little-Fiction will certainly last."

But the Gilly-Machine gave a rattle and cough, And a Gilly-Goo gear-bolt came tumbling off. The Fizz-Juice turned grey, like a puddle of mud, And the Gilly-Goo Gongs gave a hollow-type thud. Because Dot had been 'nice' to save Pip from some shame, She’d added Sunk-Cost to the Gilly-Goo game!

The socks gummed the gears! The glue gunked the wheels! (You can’t imagine how bad a Gilly-Engine feels). By 'fixing' the lie with a lie of her own, The seeds of a System-Wide-Failure were sown.

The Huddle and the Radical Audit

The Coach (the wise Goose) raised a webbed-foot on high, And looked every Gilly-Goo kid in the eye. "Wait! Stop!" cried the Coach, "Blame’s not the game! Nobody wins if we name and we shame! This failure is big, not one little mistake, Problems cascade before everything breaks."

"It isn't just Pip! And it isn't just Dot! It’s the way that we played with the data we got! We hid all the wobbles! We polished the rust! And now our Great Engine is nothing but dust. If you want to be Winners, if you want to be Teams, You have to give Truth to the Gilly-Machine's beams!"

Pip stepped to the front, with his head held up high, (For a Sovereign Player has no use for a lie). "I dropped two green Gooks! I was clumsy and slow! And I whispered a Six just to keep up the show." Dot stepped up beside him, "And I saw the Four! But I stuffed in some socks just to open the door."

They didn't feel small, and they didn't feel bad, (Though the Gilly-Goo park was still gloomy and sad). They felt like a Team with a job to get done, To clean out the Sunk-Cost so they’d have some fun!

They pulled out the fluff! They scraped out the glue! They fished out the socks (which were smelly and blue). They performed a Great Audit, they checked every gear, Until every "Fiction" was gone from the sphere. They didn't just 'sorry', they worked on the core, Until the Ground Truth was just the same as the score.

Then Pip counted Four. Just a plain, simple Four. And the Gilly-Machine gave a happy-type roar! The Fizz-Juice poured out! It was purple and bright! And the Gilly-Goo park was a beautiful sight!

"Life is a team sport!" the Gilly-Goose cried, "With no silly fictions or secrets to hide! When you play for the Truth, and you play for the Team, The world works much better than even your dreams!"

Related posts:

  1. Frontpage 2
  2. Learning from FaceBook's failures
  3. Redundancy in Data Storage: Part 2: Geographical Replication
  4. Blog
  5. The Power of Fully Open Programmability With Cisco ACI

The Lorax: A History of Silicon Valley

This is adapted from ‘The Lorax’ by the Great Dr. Seuss. If you have not read his work, please do. His stories teach beautiful lessons through the use of whimsy and wonder.

I love Dr. Seuss, so this is a thing I do. If you like it, there are links to others at the end. I make no guarantees as to the freshness of the content.

Unless someone like you cares a whole awful lot, nothing is going to get better. It’s not.

Dr. Seuss 'The Lorax'
  At the far end of tech 
 where the products are sold
 and the wind smells of sandwiches delivered half-cold,
 where no roadmap is ever delivered when told…
 is the street of the Lifted Lorax.
  
 And deep in that end, some people say, 
 if you look deep enough you can still see, today, 
 where the Lorax once stood
 just as long as it could
 before somebody lifted the Lorax away.
 What was the Lorax? 
 And why was it there? 
 And why was it lifted and taken somewhere 
 from the far end of town where the products are sold? 
 The old Once-ler still lives here.
 Ask him. He knows.
  
 You won’t see the Once-ler.
 Don’t look for his booth.
 He stays in his mansion, alone with his things,
 where he drinks cold-pressed juice
 that someone else brings.
 And on rare occasions, out of the blue,
 he tweets
 out a message
 he often repeats
 and tells how the Lorax was lifted away.
  
 He’ll tell you, perhaps…
 If you’re willing to pay.
  
 He’ll send you a link
 to an app where you lay
 one third of your equity, then sign
 NDA
 of course, he will say
 it’s always this way.
    
 He then checks the app
 triple checks the amount
 to ensure he owns you
 that you can’t dismount.
  
 Then he adds what you paid him
 to the piles of cash
 some used for the mortgage
 the rest wipe his ass.
  
 He slacks, “I will ping you by video call,
 While out on my yacht, with crappy sig-nal.
  
 BLURRP!
 The blurps of his call, ring loud in your ear
 and the old Once-ler’s voice is not at all clear,
 since he’s out on the water on cell-phone connection
 choppy and garbled,
 This makes him sound
 quite verbally hobbled.
  
 “Now I’ll tell you.” He says, with his ego displayed,
 “how the Lorax got lifted and taken away…
  
 It all started way back…
 such a long, long time back…
  
 Way back in the days when “The Valley” was green
 and orchards spread far
 for a beautiful scene,
 and a house could be bought by a regular Jane…
 one morning I came to this place I remain.
 And I first saw the schools!
 Stanford and Berkley
 their talent you see!
 So much innovation, but money was lacking,
 an untapped resource, for someone like me.
  
 Between them a freeway Junipero Serra
 with a great halfway point up above Santa Clara
 where Sand Hill Road sat, doing just fine, in a soon to die era.
  
 From the nearby South bay
 came cool morning breezes
 which moistened the fruit
 as it hung in the treeses.
  
 But that talent! Those brains!
 Those smart engineers!
 All my life I’ve been searching
 seeking to obtain
 a resource like this
 that I could abuse.
 A resource I’d care about,
 If I’d read Dr. Seuss.
  
 My heart leapt with joy,
 I’d be an investor!
 I leased a small space
 Near an old shopping center
  
 With GREAT BRAINS AND SKILL, plus some damn lucky timing, 
 We started to watch, our net-worth start climbing.
 In no time at all, I had built a small group
 so I cut down an orchard, at the end of the loop.
  
 The moment I’d finished, I heard W-T-F!
 I looked.
 Something popped out of a plum that had struck
 the ground next to where the last tree lay dead,
 His looks were as strange as the things that he said.
  
 He was small. He was old.
 Had a drawl and was bossy.
 He looked straight on over
 Like he didn’t even know me.
  
 “Douche bag! He said, with a stern knowing tone,
 “I am the Lorax. I speak for what’s grown.
 I speak for what’s grown and warn of what comes!
 And I demand to know, what you’ve done to my plums”-
 He was winded and red; his anger was showing.
 “Why the hell would you destroy, all the things that are growing!”
  
 “Look bro” I said. “No need to get pissy.
 It’s one little orchard. No one will miss. See?
 I’m saving the world. This thing is a network.
 To connect all the people, he said as he smirked.
 It’s a book. It’s a phone. It’s music! It’s apps!
 But it has more to offer than all of that crap!
 You can use it for ads and make tons of money!
 Selling people like products while they use a freebie”
  
               The Lorax replied,
               “Dude, your ego is large, so this may just sting.
               There is no one on earth
               who would need such a thing.
  
 Just as my mouth opened to say “go-to-hell”
 around the corner came AOL,
 they thought this web would be great for a buck.
 They hired some people and backed up a truck.
  
 I clowned the old Lorax, “You stupid old man!
 You’ll never quite get, what we just began!”
  
 “I repeat cried the Lorax,
 I speak for what’s grown!”
  
 “You’re expired. I told him.
 “Go retire in peace.”
  
 I ran for the phone, in those days they plugged in,
 I put in quick calls to nephews and cousins.
 I called all my friends, my college frat buddies
 said here’s the scoop, lets go make some monies!
 We’re going to make the old world move forwards!
 Get over here fast, take the road through the orchards,
 Turn left when there’s strip malls instead of more woods.
  
 And in no time at all,
 the cement was flowing,
 buildings and car lots sprung up in quick fashion,
 concrete and rebar were doing the growing.
 We ‘innovated’
 and we stayed very busy,
 with two maybe three drinks at lunches
 wining and dining,
 betting millions on hunches.
  
 Then…
 Hello, there, hello!
 How the money did flow!
 We needed more buildings
 more car lots
 more blow!
  
 So we cleared orchards with speed
 driven purely by greed.
 We were changing the world
 this was progress we said.
 And that Lorax?...
 We guessed he was dead.
  
 The very next month
 a knock at the door
 open it up, and he’s standing there.
  
 He bellowed, “I’m the Lorax, I speak for what grows,
 Which you are destroying, wherever it shows.
 But I’m also in charge of the birds and the bees
 Who live on the fruit of these orchard trees
 and gorge on the nectar and fruit as they please.”
  
 “Because of your buildings, your car lots, and malls
 there’s not enough food for the winter and falls.
 My poor birds and bees and dying in droves
 the rest are out searching for new homes and new groves.”
  
 “This was paradise to them, but now they must go.
 They require new orchards where their families can grow.
 Good luck my fine friends,” he said as he hung his head low.
  
 I, the Once-ler, felt something
 As I watched them all go.
 BUT…
 Money I worship!
 And I’ve got plenty of blow.
 Who needs birds anyway? I drive a Lambo.
  
 It wasn’t intentional. I didn’t want that.
 But bigger is better when wallets are fat.
 I biggered my bets. I biggered my tech.
 I biggered my campuses. I biggered my head.
 Our tech started shipping, all over the globe
 from Bangkok to Paris and back to Latrobe.
 So I kept on biggering… selling more tech.
 And I biggered my wealth, with each inbound check.
  
 Then there he was, the Lorax was back
 That angry old coot with more shit that was whack.
  
 “I am the Lorax,” he choked through a cough.
 Clearing his throat he readied a scoff.
 “Once-ler!” He roared, with the rasp of his age.
 “Once-ler! The air’s filled with smog. Disengage!
 My poor lotis butterfly, well they can’t see their way.
 At this rate we’ll lose sight of the sun through the day.
  
 “And so,” said the Lorax,
 “-please pardon my tone
 They can’t survive here.
 I’ve sent them off to places unknown.”
  
 “Where will they end?...
 I don’t comprehend.”
  
 “They may have to fly for week upon week
 To get away from you, and the smog that you leak.”
  
 “But worse,” cried the Lorax, his neck hair stood up.
 “Let me say a few words about this f’ng slop.
 Your plants are dumping this shit without stop.
 They build your chips and out this stuff pops.
 And what do you do with this poo smelling goo?
 I’ll show you, you self-entitled boy-man you!”
  
 “You’re killing the lakes where the Lake Splittail fish swims!
 No more can they frolic and live out their whims.
 So I’ve ordered them off. Their future is bleak.
 They’ll wander on land, flip-flopping and weak
 searching for water without oil streaks.”
  
 And then I got angry.
 So shakingly angry.
 I yelled at the Lorax, “Now listen here, Pops!
 All you do is whine, and scream Stop! Stop! Stop!
 Well, I have my liberty, sir, and I’ll tell you
 I intend to keep doing what I want to do!
 And! For your information, you Lorax, I’m going to keep biggering
               And BIGGERING
                             And BIGGERING
                                          And BIGGERING,
 Turning orchards into lots for engineers cars
 to build more tech we can trade for gold bars!”
  
 And at that very moment, we heard a loud sound!
 Outside in the orchards a tree hit the ground.
 The final fruit tree did finally fall.
 The orchards were gone, once and for all.
  
 No room. No more boom. No work to be done.
 So, in no time, my friends, nephews, cousins, every one,
 Threw up two fingers as they hopped in my cars,
 Peace out, they said as the tires burned tar. 
  
 Now all that was left was a bad smelling sky
 Office buildings, parking lots…
 the Lorax…
 and I.
  
 The Lorax said nothing. Stared through my soul…
 his stare said to me, what he saw wasn’t whole…
 as he rose to get going, his mood black as coal.
 I’ll never forget that look on his face
 when he stood one last time, to take leave of this place,
 this Garden of Eden, that I had erased.
  
 And all that the Lorax left here in this mess
 Was a pile of rocks, with one word…
 “Unless.”
 Whatever that meant, well, I just couldn’t guess.
  
 It’s ancient history now.
 But I’ve thought of it lots.
 Worried, and muddled
 to untangle the plot. 
 While Silicon Valley crumbled away
 I’ve tried to make sense
 I’ve worried, I’ve wondered,
 and not just for legal defense.
  
 “But now,” says the Once-ler,
 “Now that you’re here,
 The word of the Lorax seems perfectly clear.
 UNLESS someone like you
 Cares a whole awful lot,
 Nothing is going to get better.
 It’s not.
  
 “So…
 Listen!” cries the Once-ler
 “I’ve sent you a seed
 in it you’ll find the hope that you need.
 It’s the last of its kind, so treat it as such
 there’s no other thing, the world needs this much.
 Plant it somewhere bleak and dreary
 Feed it, water it, and in theory
 The hope will grow big and strong
 and one day the Lorax will come back along.
Oh, the Places You’ll Go! (A Cisco ACI Story)
Horton Hears Hadoop
The App on the Crap (An SDN Story)

Related posts:

  1. Intent-Driven Data Center: A Brief Video Overview
  2. Network Overlays: An Introduction
  3. Contact Us
  4. Data Center 101: Server Systems
  5. The App on the Crap (An SDN Story)

Micro-segmentation: What, Why, How?

There’s a lot of buzz around the term micro-segmentation (uSeg) and I thought I’d take some time to demystify it, starting with some history. If you’re more of a visual learner skip to the end and check out the video.

uSeg has roots in ‘zero-trust model’ type of thinking and architectures. At the most basic level the idea is to greatly enhance security models based primarily on perimeter security implementations, like firewalls.

The reason for this is simple, if you rely solely on perimeter security you are completely exposed when (not if) the perimeter is breached. The graphic below depicts this.

In the graphic a single penetration of the firewall can lead to a comprised server or workload which then becomes the attacker with no security left to stop it.

Architectures attempting to enhance perimeter security have been implemented using firewalls as a funnel for all traffic, and VLAN Access Control Lists (VACL), among other similar techniques.

The failure of these attempts comes down to four things:

  1. Visibility: limited knowledge of what traffic  can/can’t be blocked.
  2. Cost: firewall hardware, etc.
  3. Manageability: there’s no good way to manage that many distributed firewall rules or ACLs.
  4. Complexity: any way you slice it this is complex, and complexity kills agility while adding risk, cost, and reducing manageability.

Micro-segmentation spins the conversation back up in a new format. The reason it has created so much buzz is that the tools have caught up to the point where we can reduce, or eliminate the four problems above.

Technologies including big data, SDN, and advanced automation have matured enough to provide frameworks to accomplish granular segmentation at a micro, or even nano level (another term some use).

The advantage of this level of segmentation is depicted below. In the graphic a penetration of the perimeter security compromises a host or workload, but malicious traffic from that host is blocked by micro-segmentation zones. This prevents the attack from propagating further.

As the graphic depicts, micro-segmentation should not be looked at as a replacement for perimeter security, instead it is an enhancement. Micro-segmentation provides advanced  security within the secure perimeter, and in some cases can simplify, not replace,  the perimeter security architecture.

In many cases a 3rd layer of security is also implemented. This is a layer of ‘macro-segmentation.’ Macro-segmentation can be used as a starting point to micro-segmentation, deployed in conjunction, or ignored if not required.

The macro-segmentation layer provides segmentation between large static groups. Great examples are compliant vs. non-compliant, and development life-cycles (dev, test, prod, etc.)

Macro-segments can be deployed in a much wider variety of devices due to the reduced need for granularity and change. Typically macro-segmentation is deployed using Software Defined Networking (SDN) solutions.

The two primary requirements for macro-segments are broad scope, and limited change rate. The reason for this is the broader number of solutions it will deployed in. In general the more granular the scope, or the higher the change rate, the more automated the platform will need to be.

In the next graphic we see the three layers of security operating together. Each layer expands on the last becoming more granular and enhancing protection.

Micro-segmentation is the most granular of the three layers, and there are many options for how to address these segments. Micro-segments can be built around workloads (Server, VM, Container), applications (www.onisick.com, WordPress, Oracle), or traffic flows themselves (TCP X and UDP Y to IP Z). The best workload protection tools in this space offer the ability to do all three.

The ability to use various segmentation methods in parallel is important. Every environment will have different security needs. More so, within every environment different applications/data/workloads will have different needs. Having options allows you to fine-tune cost, time-to-deploy, and security risk accordingly.

The most critical thing to account for as you deploy granular segmentation will be change rate. Many tools can enforce micro-segments, very few can handle authorized change at a rate that doesn’t impact business agility.

Connectivity in a data center tends to change rapidly, static non-automated, micro-segmentation will quickly create outages based on authorized change. A great example of this is software patching.

Software patches often modify the TCP/UDP port(s) used by the application or operating system (OS). If this occurs in an environment where micro-segmentation is tightly deployed, that port change can cause outages.

The old port remains open while the new, required, port is blocked by now-outdated segmentation. Manual remediation processes for this type of thing take 48-72 hours. That will not be nearly fast enough in a micro-segmented world. This is shown below.

Micro-segmentation is a security architecture that should be explored and assessed by organizations of all sizes and types. The level of granularity required, speed-to-deploy, etc. will vary.

To take another view on this topic check out the video below that I produced on the topic.

Related posts:

  1. VMunderground Opening Acts SDN Panel
  2. Choosing The Right Private Cloud Storage
  3. Intent Driven Architectures: WTF is Intent?
  4. The Data Center Network OS – Cisco Open NXOS
  5. How Emulex Broke Out of the ‘Card Pusher’ Box

Driving Digital Transformation

Driving Digital Transformation

“Digital, Digitization, Digital, Digital, Digital Transformation. There, I've hit my mandatory quota of 5 digital mentions for my presentation, now we can get to something interesting.”

That was my opening line at a large data center and cloud conference in Rome. It wasn't the one I'd planned, but I had just spent a day listening to my executive colleagues from around the industry wax philosophically about 'digital' with no mention of how, why, or what. No call to action, no roadmap, no substance. The previous presenter was sitting front row center with his jaw wide open when I finished the sentence. He'd had digital-this, digital-that, as the title for every slide in his deck. Sorry, not sorry.

I haven't watched 'Game of Thrones' but I imagine 'Winter is Coming' might be similar to the way 'Digital Transformation' gets thrown around. 'Um yeah, it's this thing, it's on it's way, it's already happening in some places. Everyone knows what it is, definitely, for sure.' Let's agree that: it is a thing, it is happening, and it is coming in stronger waves. From there let's look at what it is, where it's coming from, and how it can be embraced.

Let's rewind to the beginning of widespread Information Technology adoption. We'll go back to the early days of networked computing and use the adoption of email systems as an example. As a company adopted email systems for the first time, they were dipping their toe into digital transformation. Paper based systems and analog based voice calls were converted to a digital medium. What that was doing under the surface was creating business value through technology adoption. That is the key to digital transformation.

Theoretically if there were two companies in the same industry and one was first to deploy and adopt an email system, they'd have a competitive advantage. The advantage of speed and agility. The hidden key phrase of the sentence being adopt. Deploying an email system wasn't enough. They had to drive adoption, incorporate it into their process and modify work flows to take advantage of it.

As technology became commonplace a shift occurred behind the scenes. Information Technology (IT) moved from a value-creation center to a cost-center. Technology purchase decisions moved from 'what can it do for the business' to how much money can we save doing the same thing. IT sales conversations shifted to circular conversations about return-on-investment (ROI), and sales cycles began incorporating any number of questionable ROI calculations.

Now comes Digital Transformation with all it's hype being treated as something new. It's not. Like most everything in technology it's circular. We're at a technology inflection point where IT can move back into the 'what can it do for the business' seat. Digital Transformation is simply using emerging technology and new IT operational models to drive new value streams for the business or mission. No more, no less.

Several things are coming together at once to form the catalyst of this shift. New technologies like big data, and AI. New consumption models like mobile first compute users. And new delivery models like cloud which provide an extremely low compute entry cost and a scale up model as a company grows. Uber is one of the most touted examples of combining these things to create market disruption, which is just silicon valley's term of the week for transformation.

Uber is an example I like, and not in the doom and gloom 'disrupt or be disrupted' way people love to use them. The question I ask my customers is different: 'If you were the taxi companies three years before Uber launched, and you had the idea for an Uber like app, could you have executed on it? Would your IT infrastructure and organization been able to build and adopt the new model?' Universally the answer is no.

The first stage of digital transformation is modernizing the technology delivery stack into a system that provides agility. Agility to test out new ideas, agility to fail and try again. Agility to deploy the bright ideas that your organization comes up with. The world moves fast, the longer it takes to process an idea, and get it stood up, the higher the chance of missing the market and being out maneuvered.

The dirty secret in all of this is that the technology is easy. There are hundreds of great options to choose from when it comes to the right technology. You can cloud it, automate it, DevOps it, etc. Alone or in tandem all of these things can work perfectly from a technology perspective to achieve your goals. The tech is easy, but most still fail.

The hard part is choosing the technology stack that fits your organization, then remodeling your people and process to take full advantage of it. Nobody likes to admit that getting new technology running is the easy part. The hard part is getting it adopted to it's fullest potential within your organization. Successfully launching a product or project internally is as important as picking the right tech and standing it up.

I look at this like Marine Corps boot camp. As a recruit we spend all of boot camp hating it and waiting to graduate, thinking boot camp is the hard part. Our drill instructors assure us boot camp is the easiest part of being a Marine. Years later we find out they were right. Boot camp, like a technology install, is fairly color by the numbers, if you follow the instructions things work as expected. Being in the fleet, post boot camp is like technology adoption. You're up and running but now it's your responsibility to apply the skills and capabilities the right way every day.

When looking at making technology shifts be ready to tackle the people and process with as much energy as you do the technology. You'll need leaders, champions, early adopters. You'll need to provide a clear sense of direction, intended outcome, and a sense of 'why'. If your team is bought in, and all moving towards the same goal the technology stack becomes a supporting character in the transformation you'll drive.

As a parting thought on Digital Transformation try and think big. I've been privileged to travel the world working with customers of all types in some very interesting places. I've gotten to see first hand the positive transformative power technology can have. From banks in Africa using cell-phone usage statistics to assess credit worthiness and provide small-business loans to people with no credit history, to hospitals in India using tele-medicine to provide advanced patient care on-site in remote villages.

Digital transformation is as much about change and a better future as it is about profit lines. Even better, the two don't have to be separate goals. This is why I wake up every morning excited to see what I can help my customers achieve that day.

Related posts:

  1. Intent all of the things: The Power of end-to-end Intent
  2. The Cloud Rules
  3. Choosing The Right Private Cloud Storage
  4. Data Center Bridging Exchange
  5. Contact Us

IT Needs its Gates and Jobs

Scour the data sheets and marketing of the best business technology hardware and software and you will see complexity. You will see references to ports, protocols, abstractions, management models, object-oriented and non-object-oriented practices, etc. Hand that data sheet to a highly-intelligent, well-educated lay-person and you will get a blank stare.

It often feels like we thrive on the complexity, we water it, we feed it, we want it to grow big and strong. Maybe we do -- maybe that complexity exists so that as masters of it we can command higher salaries – maybe it’s just a byproduct of moving so quickly. Either way it needs to change.

Hand your iPad to a child and within minutes they’re navigating through their favorite videos or playing a beloved game; no instruction or education is required. Hand an English major an SSH session and ask them to configure your switch, results will vary. Move up to our most common high-level abstraction ‘the orchestration layer’ and ask them to deploy an application. No dice.

This complexity isn’t necessary. This complexity can go away, it really can, but we’re missing something.

Enterprise technology is actually missing two things: the Bill Gates, and the Steve Jobs.

Sordid and detailed history aside Gates and Microsoft made computing a reality for the masses. The combination of good-enough technology in Windows, combined with powerful vision, sales, and marketing moved the PC into every home.

Jobs took this to another level and turned technology into art. His genius was in simplicity; providing consumers with technology they never knew they needed but could from that point forward never live without. He did this by combining hardware, software and service into experience. The iPod wasn’t a device like its competition. The iPod was the hassle-free experience of listening to exactly what you wanted, wherever you wanted to listen.

And then we return to enterprise technology. Even the sales pitch is atrocious. We focus on individual value propositions of point products. We occasionally get bold: tying a handful of products into a ‘solution’ and espouse the specific values of that solution in isolation. Never do we discuss the value to the business, the experience of the user. We never discuss anything that has true value, or real differentiation.

All is not lost, there are emerging technologies and trends that look to address this. Intent driven systems, and ‘Serverless’ are on the right track. They speak to the overall experience of architecting/deploying applications or coding/building them respectively. This is a major move in the right direction.

This move still needs help:

As consumers of enterprise tech, we must be more open to looking towards vision and outcomes. In fact, we must demand that the sellers we communicate with articulate that first.

As sellers, we must learn how to weave technology together for the higher-level purpose of those outcomes. We must then learn to communicate it in that fashion and get religious about doing so.

As vendors we must move from building products in isolation. A move to building products and driving trends that focus on tangible vision, and business outcomes.

As an enterprise technology community, we must hope for our Gates, and our Jobs. Our visionary leaders who can provide us the hope required so that we can buy into that vision and move forward towards it.

Technology should be simple to consume. It takes hard work and understanding to keep it that way.

Related posts:

  1. Negotiating Your Career
  2. Data Center 101: Server Systems
  3. A Salute to Greatness
  4. Intent Driven Architecture Part III: Policy Assurance
  5. Reassesing 'Vendor Lock-In'

What Product Management, Sales, and Job Candidates Have in Common

Pop quiz hot-shot. What do the following three people all have in common?

Answer: They must all understand how to define value, understand how that value differentiates, and be able to definitively communicate that differentiation.

I'll call these the 3–Ds' of Winning because they are applicable almost anywhere you look.

I think you get the point. We often classify these as sales skills. That's a mistake. That's like saying the body's 'motor-skills' are 'driving-skills.' Sure they help with driving, but they have much broader applicability. The reason this is important is that if you think of them as sales skills it's too easy to write them off: 'I'm not in sales', or 'I hate sales.' Letting yourself fall into this trap does nothing but sell yourself short every time. Reclassify these skills as tools you use for winning the game of life. Just like the game of life you can hone things and use them to play with integrity by the rules, or take a different path. That's your decision, and the one that decides if the skill is sleazy, or underhanded.

The nice thing about the 3–Ds' of winning is that they neatly describe a 3–step path required to position value in a way that separates whatever is being positioned from the pack. We live in a world of options, and instant access to information. If you can't find a way to remove yourself from the noise you're in trouble.

I like the example of a corporate restructure or lay-off. They happen all the time, and cut some number or percentage from the work force. It's a common trimming tool for companies, and can easily be argued as a necessary one. When they occur, the CFO along with the top executives decide a dollar figure, workforce percentage, number of head-count, etc. that they need to cut. They then pass this down the chain in some fashion.

Here I am Joe, a Director at the company and I'm tasked with cutting 20% of my team which means two of my ten people have to go. This sucks. I've been the right combination of adept and lucky in my leadership roles. So much so that I can say that I've built high-performance teams. At best I've had teams where I'd classify each member as excellent and my manager peers would agree. At worst I've had one complete dud hanging around. Let's take that case.

Step one is obviously easy. The dud is my first choice of the two. I don't like letting people go, but I also don't like wasting my time on people who refuse to take ownership of their deficiencies and their growth. If you're the 'world happens to me' type, go work for someone else. As I said, step one is easy. Whether that person has been at the company 20 minutes, or 20 years I won't lose sleep over cutting them if they are the dud I just described.

Step two is hard. Step two sucks. Step two will keep me up for weeks. Nothing about the necessity of a restructure, maintaining share-holder value, etc. makes it any better. How do I decide between 8 excellent employees? There's honestly no good way to do this. It's probably going to boil down to one of the following regardless of who you are or where you work.

Now if 8 of my remaining 9 have differentiated themselves and the 9th is an excellent technical contributor, with outstanding work ethic among a company where there are a lot of those, I know who to cut. Obviously team member 9 is excellent, I have no complaints with them, what they do daily is commendable, it just isn't differentiated. Worse, maybe it is differentiated but I don't know how it is.

Take this thought experiment one step further. Let's say all 9 of my remaining team members are excellent and visibly differentiated after selecting the dud for the cut. This poses a brilliant opportunity for me, and them. I can now use the 3–Ds' of Winning to identify that unique, differentiated value-proposition and communicate it to my leader.

I can make a very valid case for why I can only cut one from my team. I have a real opportunity to remove the hard decision, and keep my high-performance team in tact. This is not theoretical, this happens regularly. Ever notice those leaders that only make shallow cuts, if any at all? This is what they're doing.

I hope that quick example shows you both how important the 3–Ds of Winning are, and how widely applicable they'll be for you. So where do you start? For the following I'm going to focus on the idea of defining your own value for the purpose of salary/promotion negotiation or a job-interview. I'll leave it to you to make the simple fluid wording adjustments to apply the same questions, and concepts to your team, your product, your company, etc.

Define Your Value

The questions are easy, the answers take thought, self-reflection, and time. Get comfortable with being uncomfortable because you need to really sell yourself here.

These are just examples, formulate your own, or grab a book on the subject. The key is to express who you are, and what you do in succinct value statements.

Here's one of mine I bring a unique ability to communicate information, regardless of the format. My super power is making the complex relatable.

Differentiate

Step back once you have your value statements. Think about those statements from the perspective of the person who needs to buy that value. I find it easiest to start with what they don't care about. It narrows the process down quickly.

I'll stick with me as the example. Maybe my direct manager doesn't care bout communication in my role, maybe they want me heads down building technical architecture guidelines rooted in system configuration. Does that mean I don't have unique value. I hope not (although in my case, many would argue yes.) Time to modify my value statement.

My ability to communicate information allows me to make the architectural relatable, bringing business relevance and readability to system configuration.

I haven't changed the root value at all, I simply word-smithed it into a format that relates more directly to my intended audience. This step is key. Gas mileage isn't relevant to someone buying a Corvette in order to go 0–60 in 2.8 seconds. Pick a value that can apply, then make it apply. Try to come up with 3 tailored value statements.

Run them through a litmus test for differentiation. Could any of my peers theoretically say me too? If so, it's time to play with them a little more until they are uniquely differentiated. Back to myself as an example. Maybe I'm on a team of brilliant people, maybe two of them can do this as well, or close enough that it doesn't matter. I'm obviously not going to go competitive against my peers, so to avoid that I need to differentiate more.

My ability to communicate information allows me to make the architectural relatable bringing business relevance and readability to system configuration. The unique value I bring is in tying the business outcome to the technology.

Now I'm separated from the pack, without undermining anyone else. Where I'm unique is understanding the business and bringing the conversation down from that level. My peers still have room for differentiation, they can go deeper and swim with the propeller heads, fantastic! Overall you need both.

Definitively Communicate

This tends to be the hardest piece, especially for people who are extremely technical or extremely humble. The only solution is practice. You can't expect people to always see your value, if you aren't willing to guide them. Your leaders are worried about this for themselves, at the same time they are for their team. Meanwhile the have a job to do, it's easy for you and your value to get lost in the noise.

Start with a video camera or mirror, practice communicating this value. Read some books on this subject, and find ways to start communicating in public. Pipe up in meetings, attend toast-masters, stand up at an Alcoholics Anonymous meeting and tell your story. Where you do it is irrelevant, that you do it is imperative.

My accompanying video: https://youtu.be/3E7kdpntsaY

For more on the overall subject of Career and Salary negotiation check out my YouTube channel on the subject. Plenty of content there, and more coming every week:

https://www.youtube.com/channel/UCQYtv3NzUiFFHHI9XLsIGQA

You can also grab a shirt or mug to remind you that it's Your Career | Your Rules: https://teespring.com/stores/define-the-cloud

 

 

 

 

Related posts:

  1. Data Center 101: Server Systems
  2. A Salute to Greatness
  3. A Few Good Apps
  4. Learning from FaceBook's failures
  5. My Career | My Rules

Negotiating Your Career

In this 35 minute video I provide some advice for building your career, putting a price on your value, and negotiating for salary/promotion. I'm having some issues with the frames display so the direct link may be better for you: https://youtu.be/ER5msIAx7do

Related posts:

  1. A Salute to Greatness
  2. Cloudy with a 100% Chance of Cloud
  3. IT Needs its Gates and Jobs
  4. The Data Center Network OS – Cisco Open NXOS
  5. How Emulex Broke Out of the ‘Card Pusher’ Box

Cloudy with a 100% Chance of Cloud

I recently remembered that my site, and blog is Called Define the Cloud. That realization led me to understand that I should probably write a cloudy blog from time to time. The time is now.

It's 2018 and most, if not all of the early cloud predictions have proven to be wrong. The battle of public vs. private, on-premises vs. off, etc. has died. The world as it sits now uses both, with no signs of that changing anytime soon. Cloud proved not to be universally cheaper, in fact it's more expensive in many cases, depending on a plethora of factors. That being said, public cloud adoption grew, and continues to grow, anyway. That's because the value isn't in the cost, it's in the technical agility. We're knee deep in a transition from IT as a cost center back to it's original position as a business and innovation enabler. The 13.76 white guys that sit in a Silicon Valley ivory tower making up buzzwords all day call this Digitization, or Digital Transformation.

Goonies

 

Down here, it's our time. It's our time down here…

It’s also our time. Our time! Up there!

 

<rant>

This a very good thing. When we started buying servers and installing them in closets, literal closets, we did so as a business enabler. That email server replaced type written memos. That web server differentiated me from every company in my category still reliant solely on the Yellow Pages. In my first tech job I assisted with a conversion of analog hospital dictation systems to an amazing, brand-new technology that was capable of storing voice recordings digitally, today every time you pick up a phone your voice is transmitted digitally.
Over the next few years the innovation leveled out for the most part. Everyone had the basics, email, web, etc. That's when the shift occurred. IT moved from a budget we invested in for innovation and differentiation, to a bucket we bled money into to keep the lights on. This was no-good for anyone involved. CIOs started buying solely based on ROI metrics. Boil ROI down to it's base-level and what you get is 'I know I'm not going to move the needle, so how much money can you save me on what I'm doing right now.'
The shift back is needed, and good for basically everyone: IT practitioners, IT sales, vendors who can innovate, etc. Technology departments are getting new investment to innovate, and if they can't then the lines-of-business simply move around them. That's still additional money going into technology innovation.

</rant>

One of the more interesting things that's played out is not just that it's not all or nothing private vs. public, but it's also not all-in on one public cloud. The majority of companies are utilizing more than one public cloud in addition to their private resources. Here are some numbers from the Right Scale State of the Cloud 2018 report (feel free to choose your own numbers, this is simply an example from a reasonable source.) Original source: https://www.rightscale.com/lp/state-of-the-cloud.

So the question becomes why multi-cloud? The answer is fairly simple, it's the same answer that brought us to today's version of hybrid-cloud with companies running apps in both private and public infrastructure. Because different tasks need different tools. In this case those tasks are apps, and those tools are infrastructure options.

Cloud Bursting

As an industry we chased our tails for quite a while around a crazy concept of 'Cloud Bursting' as the primary use-case for hybrid-cloud. That use case distracted us from looking at the problem more realistically. Different apps have different requirements, and different infrastructures might offer advantages based on those requirements. For more of my thoughts on cloud bursting see this old post: https://www.networkcomputing.com/cloud-infrastructure/hybrid-clouds-burst-bubble/2082848167.

Once we let that craptastic idea go we moved over to a few new and equally dumb concepts. The cloud doomsayers used a couple of public cloud outages to build FUD and people started fearing the stability of cloud. People of course jumped to the least rational, completely impractical solution they could: stretching apps across cloud providers for resiliency. Meanwhile those companies using cloud, who stayed up right through the cloud outages laughed, and wondered why people just didn't build stability into their apps using the tools the cloud provides. Things like multiple regions and zones are there for a reason. So some chased their tails a little on that idea. Startups started, got funded, and failed, etc., etc.

Finally we got to today, I rather like today. Today is a place where we can choose to use as many clouds as we want, and we're smart enough to make that decision based on the app itself, and typically keep that app in the place we chose, and only that place. Yay us!

 

Quick disclaimer: Not all multi-cloud came from brilliant planning. I'd take a guess that a solid majority of multi-cloud happened by accident. When cloud hit the market IT departments were sitting on static, legacy, silo'd infrastructure with slow, manual change-management. Getting new apps and services online could be measured in geological time. As organizations scrambled to figure out if/how/when to use cloud, their departments went around IT and started using cloud. They started generating revenue, and building innovation in the public cloud. Because they went out on their own, they picked the cloud or service that made sense for them. I think many organizations were simply handed a multi-cloud environment, but that doesn't make the concept bad.

Now for the fun part. How do you choose which clouds to use? Some of this will simply be dictated by what's already being used, so that parts easy. Beyond that, you probably already get that it won't be smart to open the flood gates and allow any and every cloud. So what we need is some sort of defined catalogue of services. Hmm, we could call that a service catalogue! Someone should start building that Service Now.

Luckily this is not a new concept, we've been assessing and offering multiple infrastructure services since way back in the way back. Airlines and banks often run applications on a mix of mainframe, UNIX, Linux, and Windows systems. Each of these provides pros, and cons, but they've built them into the set of infrastructure services they offer. Theoretically software to accomplish all of their computing needs could be built on one standardized operating system, but they've chosen not to based on the unique advantages/disadvantages for their organization.

The same thinking can be applied to multi-cloud offerings. In the most simple terms your goal should be to get as close to one offering (meaning one cloud, public or private) as possible. For the most part only startups will achieve an absolute one infrastructure goal, at least in the near term. They'll build everything in their cloud of choice until they hit some serious scale and have decisions to make. If you want to get super nit-picky, even they won't be at one because they'll be consuming several SaaS offerings for things like web-conferencing, collaboration, payroll, CRM, etc.

There's no need to stress if your existing app sprawl and diversity force you to offer a half-dozen or more clouds for now. What you want to focus on is picking two very important numbers:

  1. How many clouds will I offer to my organization now?
  2. How many clouds will I offer to my organization in five years? It should go without saying, but the answer to #1 should be >= the answer to #2 for all but the most remote use-cases.

With these answers in place the most important thing is sticking to your guns. Let's say you choose to deliver 5 clouds now (Private on DC 1 and DC 2, Azure, AWS, and GCP). You also decide that the five year plan is bringing that down to three clouds. Let's take a look at next steps with that example in mind.

You'll first want to be religious about maintaining a max of five offerings in the near term, without being so rigid you miss opportunities. One way to accomplish this is to put in place a set of quantifiable metrics to assess requests for an additional cloud service offering. Do this up-front. You can even add a subjective weight into this metric by having an assigned assessment group and letting them each provide a numeric personal rating and using the average of that rating along with other quantifiable metrics to come up with a score. Weigh that score against a pre-set minimum bar and you have your decision right there. In my current role we use a system just like this to assess new product offerings brought to us by our team or customers.

The next step is deciding how you'll whittle down three of the existing offerings over time. The lowest hanging fruit there is deciding whether you can exist with only one privately operated DC. The big factor here will be disaster recovery. If you still plan on running some business-critical apps in-house five years down the road, this is probably a negating factor. Off the bat that will mean private cloud stays two of your three. Let's assume that's the case.

That leaves you with the need to pick two of your existing cloud offerings to phase out over time. This is a harder decision. Here are several factors I'd weigh in:

In the real world no decision will be perfect, but indecision itself is a decision, and the furthest from perfect. If you build a plan that makes the transition as smooth as possible over time, gather stake-holder buy-in, provide training etc., you'll silence a lot of the grumbling's. One way to do this is identifying internal champions for the offerings you choose. You'll typically have naturally occurring champions, people that love the offering and want to talk about it. Use them, arm them, enable them to help spread the word. The odds are that when properly incentivized and motivated your developers and app teams can work with any robust cloud offering you choose public or private. Humans have habits, and favorites, but we can learn and change. Well, not me, but I've heard that most humans can.

If you want to see some thoughts on how you can use intent-based automation to provide more multi-cloud portability check out my last blog: http://www.definethecloud.net/intent-all-of-the-things-the-power-of-end-to-end-intent/.

Related posts:

  1. Your Technology Sunk Cost is KILLING you
  2. The Cloud Rules
  3. Post defining VN-Link
  4. Why You’re Ready to Create a Private Cloud
  5. Technology Passion

Intent all of the things: The Power of end-to-end Intent

Intent

The tech world is buzzing with talk of intent. Intent based this, intent driven that. Let's take a look at intent, and where we as an industry want to go with it.

First, and briefly, what's intent? Intent is fairly simple if you let it be, it's what you want from the app or service you're deploying. Think business requirements of the app. Some examples are the apps requirements for: governance, security, compliance, risk, Geo-dependency, up-time, user-experience, etc. Eventually these will all get translated into the technical garbage language of infrastructure, but at some point they're business decisions, that's exactly where we want to capture them. For the purpose of this post I'll focus on using intent for new apps, or app redesign, discovering intent for existing apps is a conversation or ten in itself.

There are several reasons we want to capture them at this level. Here are a few:

Conceptually any intent based, or driven, system will capture this intent at the highest level in a format abstracted from implementation detail. For example, financial regulations such as PCI compliance would be captured in intent. That actual intent will be implemented by a number of different devices that can be interchanged and acquired from different vendors. The intent, PCI compliance, must be captured in a way that separates it from underlying configuration requirements of devices such as firewalls.

The actual language used to define the intent is somewhat arbitrary but should be as universally usable as possible. What this means is that you'd ideally want one intent repository that could be used to provision intent for any application on any infrastructure, end-to-end. We obviously don't live in an ideal world so this is not fully possible with current products, but we should continue to move towards this goal.

The next step of the process is the deployment of the intent onto infrastructure. The infrastructure itself is irrelevant, it can be on-premises, hosted, cloud, unicorn powered, or any combination. In most, if not all, products available today the intent repository and the automation engine responsible for this deployment are one and the same. The intent engine is responsible for translating the intent description stored in the repository down onto the chosen supported infrastructure. In the real world the engine may have multiple parts, or may be translated by more than one abstraction, but this should be transparent from an operational perspective. This process is shown in the following graphic.

Intent System

Now's where things start to get really sexy, and the true value of intent starts to shine. If I have an intent based system with a robust enough abstraction layer, my infrastructure becomes completely irrelevant. I define the intent for my application, and the system is responsible for translating that intent into the specific provisioning instructions required by the underlying infrastructure whatever that infrastructure is, and wherever that infrastructure lives (private, public, hosted, Alpha Centauri.)

The only restriction to this is that the infrastructure itself must have the software, hardware, and feature set required to implement intent. Using the PCI compliance example again, if the infrastructure isn't capable of providing your compliance requirements, the intent system can't help make that happen. Where the intent system can help with this is preventing the deployment of the application if doing so would violate intent. For example you have three underlying infrastructure options: Amazon EC2, Google Cloud Platform, and an on-premises private-cloud, if only your private-cloud meets your defined intent then the system prevents deployment to the two public cloud options. This type of thing is handled by the intent assurance engine which may be a seperate product or component of one of the pieces discussed above. For more on intent assurance see my blog http://www.definethecloud.net/intent-driven-architecture-part-iii-policy-assurance/.

This is where I see the most potential as this space matures. The intent for your application is defined once, and the application can be deployed, or moved anywhere with the intent assured, and continuously monitored. You can build and test in one environment with your full intent model enforced, then move to another environment for production. You can move your app from one cloud to another without redefining requirements. Equally important you can perform your audits on the central intent repository instead of individual apps as long as the infrastructures you run them on have been verified to properly consume the intent. Imagine auditing your PCI compliance intent definition one time, then simply deploying apps tagged with that intent without the need for additional audits. Here's a visual on that.

 Multi-Cloud Intent

Now let's move this one step further: end-to-end intent. The umbrella of intent applies from the initial point of a user accessing the network, and should be carried consistently through to any resource they touch, data center, cloud, or otherwise. We need systems that can provide identity at initial access, carry that identity throughout the network, and enforce intent consistently along with the traffic.

This, unsurprisingly, is a very complex task. The challenges include:

The bright side here is that products to handle each portion of this exist. At least one vendor has a portfolio that can provide this end-to-end architecture using several products. The downside or fine print is that these all still exist as separate domain products with little-to-no-integration. I would consider that more of a consideration than an adoption road-block. Custom integration can be built, or bought, and you can expect product integration to be a top road map priority. The graphic below shows the full picture of an intent driven architecture.

End-to-end Intent

Utilizing intent as the end-to-end policy deployment method provides an immense amount of value to the IT organization. The use of intent:

While Intent driven architectures are in early maturity levels, they are already being deployed fairly widely in various fashions. As the maturity continues to grow here are some things I'd like to see from the industry:

Related posts:

  1. Your Technology Sunk Cost is KILLING you
  2. Data Center Analytics: A Can’t Live Without Technology
  3. Intent Driven Architectures: WTF is Intent?
  4. Best Practices of Women in Tech
  5. Reassesing 'Vendor Lock-In'

Reassesing 'Vendor Lock-In'

Lock in is an oft discussed consideration when making technology decisions. I tend to see it used more by vendors seeding Fear Uncertainty and Doubt (FUD), but I also see it in the native decision making processes of many of my customers. Let's take a look at it, starting with what it really is. I've dabbled into this topic a bit in the past if you're interested: http://www.definethecloud.net/the-difference-between-foothold-and-lock-in/.

If you're an American the best example I have is your cable company. Those bastards have you locked-in. At some point in human pre-history they footed some of the cost of getting cable run to neighborhoods, and the homes in them. They used that investment to lobby politicians into providing them government protected monopolies. Since then they've spent obscene amounts of money keeping your politicians fat and happy in order to maintain that monopoly. Don't like their pricing, offering, etc? Too F'ng bad. If you want decent broadband internet access, you'll be paying them. Because you already pay them for that, you'll probably lump in some cable TV. A content medium allowed to stay horrible and antiquated based on the above monopoly. In short, you're locked-in.

This is the most extreme form of lock-in, but it does a good job of illustrating the point. Lock-in can be a natural effect of the technology, purposefully driven into products by the vendor, or even driven through law and governmental controls such as above. Lock-in is real, exists all over the place, and can range from annoyance to being a real problem creating huge costs to the end-user as is the case above. FYI if you want to do something about that above monopoly skip voting about it unless you're a fan of wasting your time. Instead use your wallet and switch to your cell-provider for home broadband when they start offering it in your area, then dump cable TV in exchange for the plethora of internet TV options.

Now let's take a deeper look into lock-in starting on the consumer side. Love them or hate them, Apple has one of the most locked-in eco-systems in the consumer world. They beautifully tie their hardware and software together building an eco-system where each Apple product often only works with others, and each Apple product is greatly enhanced by the next. You like the IOS experience, great, buy an iPhone. Love your Android phone but really want that shiny Apple watch? Time to replace that phone. Even the default browser on the phone is Apple software. Companies that want into that closed system pay for it. Google is reportedly about to pay Apple $9 Billion for the privilege of staying the default search engine (https://9to5mac.com/2018/09/28/google-paying-apple-9-billion-default-seach-engine/.) Even their cable, and interfaces are often proprietary forcing you to buy their expensive eco-system of accessories and adaptors, which from what I hear tend to change with every new phone.

Now, while that's a lot of lock-in it isn't necessarily a bad thing, and shouldn't necessarily keep you from buying Apple. It is the reason I don't buy Apple products but not simply because the lock-in exists. I don't buy Apple because the devices, prices, features, as a whole don't outweigh the lock-in for my personal use-cases. That is going to be a different decision for every individual. The moral of the story is that the existence of lock-in shouldn't bar you from choosing a product, but it should be weighed against all of the other factors. In my case, if I was willing to switch from PC to Mac that would be the tipping point to switch me into the entirety of the Apple eco-system.

Now let's move up the stack to enterprise tech. There is a lot of real and perceived lock-in. Networking is a great example of where it gets talked about a lot. Interoperability in network is driven through standards, but those standards move s-l-o-w-l-y. Often networking vendors launch features, protocols etc. before they become standardized. This typically means that the feature will only work with their equipment and software. In these cases it doesn't mean you shouldn't use it, if you need it now, you need it now. Again, you weigh the advantages against the risks, just like every other decision.

As we move to cloud, the lock-in conversation appears again. Each cloud uses it's own API, provides it's own interfaces, and features, nearly all proprietary. If you design and build an application on cloud a, you'll need to redesign and build it if you want to move. This creates a perceived lock-in problem. Should I put all of my eggs in one basket knowing I have a costly transition if I ever need it? Should I design my apps to run on multiple clouds? Should I attempt to implement some form of cloud broker that can abstract the underlying architecture and provide cloud portability?

These are valid questions, and will have to be assessed at some level within every organization. That being said, the potential lock-in should not turn you off from cloud adoption. The on-premises infrastructure you've been running for years has as much, or more, lock-in than any cloud you may move to.

The biggest pitfall to avoid comes in the form of a specific form of multi-cloud deployment in which organizations attempt to build apps for multiple clouds. This will almost always be a mistake, whether it's to avoid lock-in or some misguided disaster recovery/business continuity strategy. The issue with this method is the significant cost and complexity involved in trying to build an application capable of running on multiple-cloud environments. These will almost always outweigh the perceived benefits.

Multi-cloud is not a bad thing, but avoiding lock-in should not be a primary factor. Additionally when looking at deploying a multi-cloud environment you should be looking to do so on a per app basis, not disaggregating an individual app. There will also be some limited use-cases where individual application tiers, or components may reside on separate private or public cloud infrastructures.

In almost all technology cases your complexity and overall operational costs will be exponentially lower the fewer vendors you utilize. From sales calls, product updates, to integration points and customization each additional vendor adds cost. This doesn't mean that you should move to single vendor strategies, it does mean you should assess the decision carefully. You want a dual-vendor strategy at each technology tier, great, stick to two. You want to choose a single vendor for each piece of the stack, fantastic. Either way align the costs and complexities, to the benefit they provide.

The downside of lock-in is universally exaggerated. The real question is whether you're getting the value from the product you need, in an eco-system that supports your requirements, at a cost you can afford to pay. If those things weigh out, then any real or perceived lock-in becomes a complete non-issue.

Related posts:

  1. Bacon And Eggs as a Service (BAEaaS) at VMworld
  2. Intent all of the things: The Power of end-to-end Intent
  3. Intent Driven Architecture Part III: Policy Assurance
  4. Learning from FaceBook's failures
  5. The Cloud Rules