In this video I talk with Tim Crawford (@tcrawford) about what possible pressures organizations are facing to increase cloud service adoption. Are the capabilities of the cloud more enticing then before? Should organizations be changing their application portfolio plan? Nothing is black and white, but what reality fits in between?
Given the current climate of social distancing there has been a dramatic increase in people working from home, including millions who have shown they are grossly unprepared. This post is NOT going to tell you how to become more prepared. Plenty of those already.
I think it’s important to have a quick, but frank, conversation about patience because as much as our SaaS providers want us to believe they are properly equipped for seasonal load shifts, most are NOT prepared for what we’re experiencing today and likely to experience over the next six or more weeks.
Here are a couple of things to keep in mind.
It usually takes time to spin up new resources to accommodate spikes in utilization - even in the cloud. It’s physics so please don’t @ me on this one.
The bigger issue isn’t just supporting the spike, it’s supporting the increase long-term. This changes operating and support models. I anticipate a few SaaS meltdowns this spring as teams learn their operating model wasn’t adequately prepared.
Cost models for these services did not anticipate the long-term additional traffic and not everyone is going to open the resource flood gates. They will seek balance between added cost and customer satisfaction. Current market conditions are not going to help with this for publicly traded companies. i.e. Be patient because cloud is agile, but isn’t free.
Given that so many events have gone virtual you had better believe every vendor is going to ramp up their webinars this spring (they have their numbers to meet). Anticipate many of those will not be as seamless as we’d prefer.
SaaS services aren’t the only services you’ll depend on. Keep in mind that your IT department likely hasn’t anticipated this volume either (think VPN, VoIP, etc) Be patient with them as well.
Even if your SaaS provider is prepared to do what it takes (I’m thinking Microsoft in large part because they own their own cloud). More people at home means a disproportionate load on residential internet service providers - which admittedly are already painful. This is going to compound if schools are ordered to close for an extended period. It’s never too early to teach your kids about bandwidth, traffic shaping, and latency!
Implementing for this scale of remote workers is not generally done for most companies. It’s honestly not cost effective for typical usage so this is completely understandable. However, our industry has the capacity to keep things rolling during this time frame. It’s just important to maintain some sympathy to our fellow technology professionals. Extend some #HugOps and be patient when things don’t work the way you’d like them to. If they are working brilliantly feel free to send out thanks. It will be appreciated.
Stay safe. Wash your hands. Keep calm and carry on!
Our careers need not be a linear path. In reality, we should navigate our careers with an approach that is mindful of unique opportunities that allow us to grow both professionally and personally. I have tried to take this to heart and it has led me into some interesting, and often difficult transitions. One of the key transitions that gets the most interest is my move away from work that is highly hands-on and technical.
I’m an engineer through and through. Always have been. Arguably, always will be. Many of the people that I talk with each day, meet at a conference, who attend my talks, and likely read this blog are highly technical in their nature and their work. We are birds of a feather. However, I have found that a very high percentage of the highly technical I interact with have a strong hesitation, if not fear, about their technical skills diminishing. I’m often asked about my transition and, most importantly, how I’ve made it stick.
The answer is simple. I made a decision that the skills I wanted to develop and nurture going forward were not technical skills. I looked at the places where I might want to go in my career and realized I was not likely to get there nurturing the skills and work that got me to that point.
The hardest part of this transition is acceptance.
It takes time and resolve in order to step away from being hands-on technical. I believe my ultimate success was a result of gradually transitioning to jobs that required my technical capabilities less and gave me opportunities to develop other desired skills.
These transitions allowed me to develop the skills that I thought were going to be most important to me going forward. Communication, Collaboration, Community Development, Marketing, Management, Go-to-Market (GTM strategies), and Leadership. I had a desire to be seen as a trusted advisor and to help people in different capacities.
This transition has taken several years and a few job role changes. In a future post I’ll outline some of the concrete steps I took to navigate this non-linear path from highly-technical engineer to an engineer that uses his past experience in connection with newly developed skills.
If you are currently looking at your career and moving forward with hesitation because you fear your technical skills diminishing I’d love to hear from you. Hit me up on social or share with #ITTherapy #AlwaysAnEngineer on Twitter.
Hello patient readers. It’s been a while. I’ve missed you.. A great deal has changed for me in the last 3.5 years and a big part of that was a considerable change in the work I do on a daily basis, more focused on non-technical efforts, and a higher percentage of energy dedicated to my family and myself. The last couple of years have been a great transition period for me and I’m looking forward to sharing new things with you. Don’t worry. I’m keeping the old stuff up for those who still may want to reference it. vTesseract.com still lives as a domain….for now at least.
With my change in focus I’m also making some changes to the blog. First, you’ll notice that I’m moving away from vTesseract.com and transitioning to Josh-Atwell.com. Answer here is simple - vTesseract was always intended to be tongue-in-cheek response to the vSphere name. It was always tied to virtualization efforts that I worked on and shared. It no longer fits my focus today. Also, it feels worthwhile to have my thoughts and work better tied to myself.
Content going forward will focus on how IT leaders and practitioners are having to change in order to meet the growing complexity and scale of their responsibilities, something regularly referred to as NewOps. Some of this will overlap with one of my programs at Splunk called NewOps Days. My goal is to provide content that either A) Answers a question or B) Initiates the framework for a conversation on an important topic. I’m also planning to produce video and audio content to help reach audiences with multiple learning preferences. Frankly, I’ve missed personal audio and video production. I now have the gear (I <3 you iPhone 11 Pro and supportive wife) and interest to make the effort worthwhile.
That’s it for now. I hope you join me on the journey going forward. If you have a topic you’d like me to explore or a question you’re interested in having answered, please feel free to reach out on one of the social platforms listed in the right-hand bar. I look forward to sharing my thoughts and hopefully initiating some meaningful and necessary conversations.
Josh
P.S. I’m sticking with Tumblr for the time being while I evaluate how things go for the next few months. It’s not my favorite and likely not yours either. Open to your thoughts on platforms.
I recently talked with Marc Farley on is Vulcancast podcast about behavior on Twitter. I love using Twitter for engaging with people around the world. We should all work to be excellent to one another, both online and offline. Enjoy!
At the recent DevOps
Days Washington, DC I made the comment during the Ignite Karaoke that has stuck
with me. The image on screen appeared and it was a photo of Yoda on Luke
Skywalker’s back in a scene from The Empire Strikes Back. The comment
referenced a line from the recent Deadpool movie. “Devs are ridin’ a
bitches back like Yoda on Luke.”
As you might expect,
many laughs followed as I’m sure the majority of the attendees knew the movie
references. What may have been lost was a somewhat painful truth that exists
about how organizations might really be getting to DevOps Code-vana. Operations
teams are the pack mules of DevOps.
The reality with
DevOps is that it is intended to be a framework where both sides have
considerable investment stake in the outcome. Imagine a boat where the team at
the oars has Devs on one side of the boat and Ops on the other. If one side is
working at a considerably higher pace than the other there is only one long
term result. Traveling in a circle. Balance is required, yet I don’t feel that
we’re seeing that represented in the industry.
I’d like to share some
observations I’ve noted over the last 6 months as I’ve spent more time focused
on DevOps related events that supports this assertion.
Events
If you go to a DevOps
event, it’s going to be focused on the Devs. Look over the agenda and their
abstracts will have a hyper focus on the efforts of the development teams and
what they’ve achieved. What you’ll see glossed over or not mentioned at all were
the prerequisite efforts the operations and infrastructure teams delivered to
enable the deployments. This isn’t entirely surprising as most of these talks
are journey talks and who really wants to hear about the mules that carried the
gear over the mountain?
In case you’re
thinking “Here’s an Ops guy whining about Ops not getting attention.”
In a fashion you are correct. My motivations are less selfish than you may
think. The $$$ is certainly in the release of new features to customers. The
reality is that this works as a result of efforts on both sides of DevOps.
Right now the focus at events looks more like DEVops.
My issue here is less
in the fact that Ops folks are “not getting credit”, and more in that
in order for DevOps to be successful the folks in Ops have to be on board. They
are not receiving sufficient content at these events to help them overcome
THEIR obstacles and better understand how to deliver. They are already a bit
hamstrung as I’ll outline next, and the community at large is not doing them
any favors.
The other reason that
this is a huge deal is because frankly the Ops side of the house is EXTREMELY
capable of delivering services that are needed. I regularly have conversations
with customers looking to evolve who have not recognized that the features and
tools they already have contain significant value to their development teams.
Why don’t they know this? Frankly, no one has told them the pain points or not
done so in a context that is relevant to how they can deliver.
This is easily
remedied, but the organizers at these events need to make more of an effort to
include Ops focused content. The other side effect to this, which I see often
when I have an opportunity to speak, is that once the Dev focused attendees
hear about the features and capabilities the ops teams can deliver it opens up
new possibilities for them. That’s how it is supposed to be, right?
Tools
The second major
hurdle that has more focus on the Devs of DevOps is around tooling. Many
sessions will outline how specific tools were implemented in order to enable
the group’s objectives. Those tools, more often than not, are primarily focused
on the developers’ needs. I have seen very little content at these events
discussing the tools that are leveraged by the Ops side of the house in order
to facilitate the end goals.
ProTip: Many of these
tools can, and should, be leveraged on both sides of DevOps.
Again this is not
entirely surprising. After all, the developers in this space have a very
distinct advantage over the operations and infrastructure folks. They’re
developers! They can build their own tools. Traditionally the Ops side of the
house has been dependent on vendors who have worked in their space to deliver
tools to enable easier management and doing more with less. What they have not
done is demonstrate how to enable doing things faster, with a more immutable
attitude, and delivering sufficient extensibility with tool integrations to
deliver the increasing demands from the Dev organization. The demands are
reasonable. The ability to deliver for them remains difficult. This is one of
the reasons I joined SolidFire in the first place, to help expand understanding
and bridge that gap.
I’m seeing this start
to shift slightly and I believe much of it has to do with the fact that many
challenges that face Ops in the DevOps world have not been sufficiently
addressed and articulated. The tools are starting to emerge, and vendors are
starting to better understand how their products and portfolios fit into the
space. Just look at EMC Code, VMware Code, and NetApp’s ThePub which recently
launched. They’ve been in the space, but are just now understanding how to
contribute.
Conversations Askew?
This leads to the last
area where I think we’re failing DevOps. We are seriously glossing over the
amount of effort required to deliver on the needs of DevOps. This stuff is not
always easy and as the latest State
of DevOps Report demonstrates, the impact to Ops is great. I find that even
this impact is being glossed over in the report. More on that in my next post.
The report stated that
failure rates during deployments INCREASED for organizations who were
considered medium performers. Their performance status based on their frequency
of code deployments to approximately 37 times a year versus two. In the same
report we learn that the mean time to recovery actually INCREASES for these
folks as well. What the actual…ok hold on a minute. We adopt DevOps and
things get WORSE for Ops as a result?
Anyone who has carried
a pager is likely cringing at this thought. Without receiving the right
expectations, understanding the actual needs, and lacking the appropriate tools
to accommodate the new initiatives the Ops folks are left with a distinct disadvantage.
Additionally this is going to put considerable strain on the initiative. I can
only imagine how difficult it is for the leadership who are seeing their core
performance metrics see a drop as a result of a DevOps initiative. “Didn’t
you guys go to the DevOps conference and read the Phoenix Project? Why are we
doing WORSE!?”
What does this mean?
Given the items
outlined above and the results of the State of DevOps report there needs to be
a significant focus placed on getting the Ops side of the boat more information
to make them function at a higher level. We need to get them a quantity and quality
of content which is more on par with their Dev counterparts. Otherwise, the
only result is that they are going to have to paddle considerably harder just
to keep the boat from going in a circle and getting them no farther forward.
They also may not even know why. My fear is that a high percentage of
organizations are currently working in a very circular or sinuous path. It
doesn’t need to be this way. As a community we simply need to talk less DEVops
and making sure we are talking DevOps. We’re all carrying the load after all.
P.S. I’m betting the
mules have a heck of a story to tell. :-)
Dear Infrastructure Admins - Our Industry is Breaking Up with You
Dear Infrastructure
Administrator,
It’s a very somber
time for many in the IT industry. More and more infrastructure administration
jobs are going the way of the server administrator. Think about it. How many
roles out there exist today whose purpose is to manage server hardware? In my
career those roles have fallen on the owners of the hypervisor, which was
generally me but who’s counting. How many do you see today?
The reality is that
server resources quickly became abstracted with virtualization. The amount of
actual administration reduced to an occasional task versus what was formerly
steady care and feeding. We’re starting to rapidly see the same things happen to
the other elements of our infrastructure, namely networking and storage. Sorry.
I know this may feel sudden, but I’m talking to you.
I don’t want you go to
into this blindly, so here are three things I really think you should know.
The consumption model has changed. Did you miss it?
Your ability to
provision a LUN or a VLAN is rapidly becoming unimportant. The way
infrastructure is being consumed going forward is through software. Through
virtualization. Through containers. Through many things that are not you.
Infrastructure today now has the ability to enable the consumers to request,
implement, modify, and monitor the resources that they need.
VMware has introduced
Virtual Volumes which leaves the storage team a single core task of setting up
a storage container and protocol endpoints. Major snoozefest for the storage
and virtualization teams, but a huge gain for the application teams. Same is
seen in OpenStack and Docker. Good news. The number of tickets you receive
requesting resources or changing feature configurations should start going down
considerably. This capability is now available in your consumer’s hands. Same
is happening for networking with ACI and NSX. Policies all the way down. I’ve
not even talked about tools like Puppet, Chef, Kubernetes, or PowerShell.
The GUI is now a backup plan
I certainly hope
you’re learning about APIs and integrations with these new consumption tools
mentioned above. If you’re not doing the provisioning, and something else is,
then it certainly behooves you to understand HOW those technologies consume the
resources that you’re still going to have responsibility to maintain. Sure,
you’ll have some ad-hoc tasks that remind you of the good old days, but by that
time the GUI has become your backup plan.
You’re about to be so
accustomed to NOT doing those tasks you might have to brush off your GUI
skills. I promise that this will be irritating when it happens. We’re moving
on. Nobody is going to wait for you.
You won’t miss it
You consider yourself
an infrastructure administrator? That’s cool. There’s still a job for you going
forward. Chances are you’re already looking at the future and the new
mechanisms for your technology of choice to be consumed. Where do you think all
of those virtualization administrators came from? They were once server
administrators.
Keep that in mind
before you panic or start getting all nostalgic about the next ticket you get
to provision a LUN, a new VLAN, or update someone’s snapshot schedule. You
never put those things on your resume anyways. Everyone just assumes you know
how to do those things.
You should also find
that you’re about to stop caring about speeds and feeds and will start focusing
on ways to accelerate your business by staying out of the way. The catalyst for
this will vary from place to place, but the motivations will become consistent.
You are still going to care about uptime and resiliency. You’re going to have
to quickly fix things from time to time just like always. The main difference
is now this business looks to you to deliver everything more quickly and more
simply. Don’t worry, you still have to keep doing more with less. Once you
start focusing on that you’re going to be glad you don’t have to worry about
being an infrastructure administrator of the past. You wont have time. You’ll
be solving much more important problems, and glad for it.
We’ve had a good long
run. It’s not that we don’t like you. We just need to grow faster and we want
to see you do more with your time. I hope we can still stay friends.
Always yours,
The IT Industry
P.S. My Dropbox
account doesn’t seem to stay in sync any more. You know anything about that?
================================
Have a thought on this post? Share it in the comments or with me on Twitter.
This post is the first
in what I plan to be an ongoing series I’m calling Thoughts in Flight.
Basically I have a thought while on a plane and spend about 45 minutes writing
it out. My goal is to get some thoughts out there, start some conversation, and
hopefully stir the pot a bit.
Tomorrow is the day. It’s vBrisket in Pittsburgh. This time around they’ve asked me to come up and speak about Automation. As the invitation states we’re going to talk automation from 101 to black belt.
One note on this topic. People like myself can easily take for granted that automation is THE way to scale and guarantee. It’s not something that everyone has already started to implement. I’ll make sure to spend time from introduction to some advanced concepts during this timeframe and discuss the evolution.
If you’re in the Pittsburg area get signed up. SolidFire has generously agreed to sponsor the event and let me give away a surprise gift
This event will be a test unlike anything I’ve ever faced. I’ve presented at the drop of a ht. I’ve presented in full costume. I’ve presented on non-technical topics. I’ve never presented where the pervasive aroma of BBQ is a constant reminder that there is delicious food to be had.
This has been a fun couple of weeks for me as I have had some opportunity to focus some energy on PowerShell. I guess it is silly to think I ever stop doing things with PowerShell. Let’s just say I’m reinvigorated yet again. Here’s some details. Updates, if you will.
PowerShell and DevOps Summit
I’m sitting in a hotel lobby in Seattle getting jazzed up for this year’s PowerShell and DevOps Summit. This event brings many of the best and brightest PowerShell developers and hackers together to share and learn. Last year’s event in Charlotte, NC was fantastic and I expect even more this year. I also hear there will be some announcements.
I’m also excited about this year’s event because I’ve been invited to speak about automating the infrastructure stack with PowerShell. This talk is more about the gains, the challenges, and the various types of use cases for leveraging PowerShell across infrastructure layers. Finally, I’ll be introducing a concept I’ve been working on that should provide some useful gains in this area. More on that in a later post.
Cincinnati PowerShell Users Group
I’d like to send a big thanks to the great folks at the Cincinnati PowerShell Users Group for having me out a little over a week ago. They were a great audience and provided some seriously valuable feedback for my #PSHSummit talk. Follow those good folks on Twitter at @CincyPowerShell.
SolidFire PowerShell Tools 1.2
PowerShell also continues to grow at SolidFire, now part of NetApp. The development team did another superb job with the 1.2 release and filled in the remaining feature gaps. It’s exciting knowing that there are native PowerShell cmdlets to manage essentially everything in the platform! This has me excited about some of the new possibilities for leveraging the module. If you’re interested make sure you check out our announcement.
Microsoft MVP
My final piece of exciting PowerShell goodness was receiving the Microsoft MVP award for Cloud and Datacenter Management. Microsoft describes this award as:
Microsoft Most Valuable Professionals, or MVPs, are community leaders who’ve demonstrated an exemplary commitment to helping others get the most out of their experience with Microsoft technologies. They share their exceptional passion, real-world knowledge, and technical expertise with the community and with Microsoft.
I’m in amazing company with this award, including new MVP and friend, Chris Wahl over at Wahl Network. While I’m certainly honored to have been selected for this award, I’m especially excited as this program provides opportunities for expanding knowledge and networking. I feel some fun PowerShell projects coming up in my future.
That’s all for the time being. I’ll look to post content throughout this week at #PSHSummit. I’m looking at some blogging, some interviews, and plan to try out Periscope to live broadcast with people at the event. If you are interested in these broadcasts then make sure you download the app. it’s a first attempt at this so please be patient and definitely send your feedback!
This post is intended to start a discussion because I think we’re experiencing something none of us thought we’d ever see. Microsoft is ACTIVELY and aggressively embracing the Linux platform. It seems they mean business about their any developer, any application, any platform.
The latest move was the recent announcement that their flagship database product, SQL Server, will be supported on Linux platforms with the 2016 release. This is pretty huge, which I’ll discuss more in a moment. Here’s a little “timeline” on some notable Linux inclusions from Microsoft that has left many collectively dropping our jaws and asking ourselves what whacky world we’re living in. I don’t follow this super closely (yet), so please be kind.
It is clear that Microsoft is pushing to expand their applications and capabilities beyond their own operating system, which is a strong move for them as the market continues to grow and application development migrates to more cloud native and distributed applications. Add this with efforts like Windows Nano server and expansions of Azure as a hybrid cloud ecosystem you have Microsoft making a strong presence in the traditionally non-Windows space.
Another thought on this move that I find both strong and brilliant is that by decoupling the applications and frameworks from the Windows operating system they can now enable more shops to develop in many more environments. Yes, I’m aware that this is the point. Let me explain my specific thought. Traditionally navigating Windows licensing in *as-a-Service models has been wrought with perils and confusion. While the move may lead to less Windows server revenue, it’s certainly going to give Microsoft the strongest ability to grow market around their other properties. This doesn’t mean they don’t continue to create value-adds for running on Windows Server. It simply means that they’d rather you run their other applications, even if it means another OS.
I’m very curious on your thoughts and perspectives regarding Microsoft in the Linux ecosystem. Here are a few questions I’d love to hear your perspective.
Do you think traditionally open ecosystems will make moves to adopt these platforms?
Do you think Microsoft shops will simply use this as an opportunity to reduce dependency, and costs, associated with Windows Server?
At what point do you think we’ll stop being surprised by the announcements outlined above? Ever?
I also have an active twitter poll. What do you think they’ll port next?