Any sort of Cloud technology these days is super hot. There is a lot of information out there to digest.
If you have a hard time distinguishing the difference between "cloud connection services" from one vendor
with "cloud services" from other vendors, then think of it this way:
Cloud services are like the toilets.
Cloud connection services are like the sewer lines. (This area is where I work every day. Don't you love the imagery here!?)
When you spin up processes at your CSP and create "data" in the toilet, and then you find that you have to transfer it back to your cube at HQ, then that's when you need the sewer lines to send the "data" to your office. The bigger and fatter the pipes of your sewer lines, the faster the "data" transfer.
You pay one cost to buy a toilet from one vendor.
And you pay another cost to the other vendor who runs the sewer lines.
Two different services.
Two different vendor relationships.
Two different bills to pay.
In the the end, the two work together really well.
Cloud connection services examples: AWS Direct Connect, and Azure ExpressRoute
The weather is starting to get nice in Seattle.
Depicted here: me in an @intercom free tech t-shirt, @arryinseattle, and Mochi (who is in a hurry to go home and doesn't care for my #FTTF segments).
Being a free tech t-shirt aficionado, I can tell you that this @intercom one is a great t-shirt and fits me very well!
The cycle and perils of a business relationship.
The steps involved in selling a technology that is never or very rarely supposed to go down.
1. Get the meeting - hard to do.
2. Get the signature (execute the contract) - harder to do.
3. Implement the solution well - really, really hard.
4. Keep your 24x7x365 service/product up and running - EXTREMELY hard (think about five 9's of up time)
5. Re-win the business at the end of the contract - very extremely hard.
6. Repeat starting from step #1 until you die - virtually impossible.
This cycle of building a long term relationship with your vendor is strife with hazards.
Just like the post-it says "Do not turn the button off. It is not the power button & could cause a fire."
All it takes is one unwitting person to ignore the post-it and you might burn your office down to the ground.
In the six step business journey above, ONE bad experience needs approximately TEN positive experiences to get the relationship back to an "okay" state. Not a good state. Absolutely not a great state. It's just an OKAY state.
(Reference to the lifetime work of Dr. John Gottman and the work done by The Gottman Institute)
The great part about this lesson from the business world is that it also applies to our personal love lives. That's right, I'm talking about you and your significant other. And also most close friendships. Although unlike the business world, staying in a great relationship until you die is probably more common than you think.
In the course of my tv watching career I have witnessed the retirement of Johnny Carson, Jay Leno and David Letterman.
My favorite was Dave. Sad to see him go. But so happy for the epic body of work that he accomplished.
There is a secret relationship between a show tune and voice+data communications.
First get the dry voice+data communications part out of way:
Service-based companies that don’t sell anything you can hold in your hands… companies that sell Internet Access, or Voice Services or WANs, they all offer a Service Level Agreement (SLA) to their customers. Something to the effect of
“We promise our service will be up and running for X% of the year."
Some companies offer X as:
Most people know that a 100% SLA is sort of bullshit. There will be service issues. A technology glitch of some kind will get you eventually. The real question is, how much are you going to reimburse me for my lost productivity because my internet was down and I couldn’t show my boss this amazing new cat video I found on Cheezburger. Or my entire Call Center was offline with no ability to take calls from customers who wanted to order a compilation VHS tape of The Best Cat Videos of 2015. I lost revenue, so you owe me money.
One issue that is sort of lost in all the fluff of getting the best SLA possible: how hard is my service provider going to make it on me to get the credits I deserve? But that’s probably a topic for a different Yunderblog post.
People often forget how freakin’ hard it is to keep a large, complex network up and running reliably. So if you run an Enterprise network, how many minutes are there in a year that need to be accounted for? How many minutes a year of down time do you need to agonizingly tell your Director of IT, or VP of IT, CIO, CEO, and Board of Directors about?
Here is the fun and lively showtune part:
"525,600 minutes. 525,600 moments so dear. 525,600 minutes. How do you measure, measure a year?"
I love that song.
60min x 24hrs x 36days = 525,600 minutes per year
To meet an SLA of three 9’s (as the people in my business like to call it), you can be down for 0.1% of the year. So that’s 525,600 x 0.001 = 525.6 minutes.
Think about how short of an amount of time that is for an entire year. And that’s with only three nines!
People forget how good of a level of performance that is.
To meet an SLA of four 9’s, you can be down for 0.01% of the year.
So that’s 525,600 x 0.0001 = 52.56 minutes.
That's less than an hour! For an entire year!! WTF.
By all accounts, if your service provider is only down for an hour a year, you have a very, very, very dependable service provider.
To meet an SLA of five 9’s, you can be down for 0.001% of the year.
That’s 525,600 x 0.00001 = 5.256 minutes
Five 9’s is an EXTREMELY, VERY GOOD, RIDICULOUSLY GOOD amount of down time in a year. By any reasonable human measure it is pretty crazy to think that the promise being made is that your cat video or will be made available to anyone on the internet for all but 5.256 minutes a year. But again the real questions are:
Can your service provider truly deliver that kind of reliable service, and how hard will it be to get compensated for the down time?
I hope you enjoyed all the math combined with one of my favorite show tunes!
Engineering 101 - Introduction to Engineering
Weed out classes.
A war of attrition.
Empirical evidence of your chances of success here...
When I started at NC State as an undergraduate, in a big auditorium of a couple hundred brand new, eager engineering students they told us:
Look to your left. Look to your right. They won't be around by the time you graduate. And it was true. It was pretty scary to be told such a fact.
In the startup/entrepreneurial/business world, it’s even more severe:
Look left and right down your entire row of comrades. They won't be around by the end of your journey.
In the photo is showing the massive hangar of Pavilion 1 that was used at the #CollisionConf. And that’s just one Pavilion.
It is a great example of the lesson I learned from Engineering 101.
Theoretical Network Design vs Real Life Network Design
We all learn about different aspects of the world in books/classrooms/academia, but sometimes what we learn about there doesn’t really match up with how it really plays out in the real world.
Now more than ever your WAN (Wide Area Network) is more vital to your business AND your personal life than you could ever imagine. WANs are basically the fundamental plumbing of the internet. Yes, that wonderful and yet sometimes insidious world of the internet.
Network Design 101
The theoretical, book-learned way to design a Wide Area Network
1. Gather the network requirements from your team and all stakeholder teams
2. Find a list of vendors who can possibly meet your network requirements.
2a. Maybe issue an RFI/RFQ/RFP.
3. Have a virtually infinite number of meetings to finalize on which vendor is the best.
4. Select the best WAN service provider
5. Negotiate the best price possible.
6. Implement the network.
7. Live happily ever after with a solid, reliable, high functioning, super fast, and low maintenance WAN.
The real life high level steps of Wide Area Network Design
1. Figure out what functionality/features/goals are needed, important, and wanted.
2. Find out what you (or your company, as the case might be) will be allowed to spend from your IT Manager, IT Director, VP of IT, CIO, or CFO.
3. Reduce everything you wanted in step #1 to fit in the budget of what was given to you in step #2.
3a. Beat your vendors down as much as humanly possible to get more of what you wanted in step #1 with the same money from step #2.
4. Implement the network.
5. Explain to the people who set the budget in step #2 why the network doesn’t work as well as it could.
6. Repeat step #5 every month.
My name is Dae Yu.