May 18th, 2020

Share This Post With Your Social Empire!

March 12th, 2020

Bet Your SaaS is Going to Bend - and Maybe Break

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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!

Share This Post With Your Social Empire!

February 12th, 2020

Always an Engineer?

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.  

image

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.

image

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.

Share This Post With Your Social Empire!

January 22nd, 2020

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.

image

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.

Share This Post With Your Social Empire!

July 30th, 2016

Share This Post With Your Social Empire!

June 30th, 2016

Is Ops the Pack Mule of DevOps?

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.”

image

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.

image

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. :-)

Share This Post With Your Social Empire!

May 23rd, 2016

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.

Share This Post With Your Social Empire!

April 27th, 2016

vBrisket!!

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.

Register at https://www.eventbrite.com/e/vbrisket-event-automation-101-to-blackbelt-tickets-24461579242

Also keep an eye on my twitter for a possible Periscope opportunity or two.

Share This Post With Your Social Empire!

April 4th, 2016

Quick PowerShell Update

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. 

image

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.

image

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!

Until next time. Thanks for reading.

PowerShell all the things!

Share This Post With Your Social Empire!

March 8th, 2016

Microsoft + Linux = WTF?

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?

Share This Post With Your Social Empire!

Papers

Applied Industrial DevOps Modernizing Operations in Age of DevOps
Expanding Pockets of Greatness
Loading tweets...

@Josh_Atwell

Helping IT leaders and practitioners embrace transformation

The Tag Cloud