#80: When you’re first starting out in your business, you’re probably going to outsource a lot of things, like HR, payroll and even server hosting. However, over time, you might start pulling some things back in house. The question is should you bring those items back in over time and, if so, when should you do it?
If you like our podcast, please consider rating and reviewing our show! Click here, scroll to the bottom, tap to rate with five stars, and select “Write a Review.” Then be sure to let us know what you liked most about the episode!
Also, if you haven’t done so already, subscribe to the podcast. We're adding a bunch of bonus episodes to the feed and, if you’re not subscribed, there’s a good chance you’ll miss out. Subscribe now!
Viktor Farcic is a Principal DevOps Architect at Codefresh, a member of the Google Developer Experts and Docker Captains groups, and published author.
His big passions are DevOps, Containers, Kubernetes, Microservices, Continuous Integration, Delivery and Deployment (CI/CD) and Test-Driven Development (TDD).
He often speaks at community gatherings and conferences (latest can be found here).
His random thoughts and tutorials can be found in his blog TechnologyConversations.com.
We know that there are some of the biggest banks in the world are going to managed solutions. Whether when we say go, that ends up being 0.5% of the workload or 20%, that's a separate story, but that move is happening.
This is DevOps Paradox episode number 80. What Should I Outsource to a Managed Solution?
Welcome to DevOps Paradox. This is a podcast about random stuff in which we, Darin and Viktor, pretend we know what we're talking about. Most of the time, we mask our ignorance by putting the word DevOps everywhere we can, and mix it with random buzzwords like Kubernetes, serverless, CI/CD, team productivity, islands of happiness, and other fancy expressions that make it sound like we know what we're doing. Occasionally, we invite guests who do know something, but we do not do that often, since they might make us look incompetent. The truth is out there, and there is no way we are going to find it. PS: it's Darin reading this text and feeling embarrassed that Viktor made me do it. Here are your hosts, Darin Pope and Viktor Farcic.
Over the past few episodes, we talked to a couple of guys. We talked to Adam, we talked to Ant, but it wasn't Adam Ant. See what it did there. It's a bad joke. If you don't know who Adam Ant is, you're too young to be listening to this podcast or maybe not. I don't know. But part of that, we talked to Xiteit, Avi and Asaf. We've talked to a number of other people that provide services, SaaS, if you will. But we started thinking, what should we really outsource to a managed solution? Could that be everything? Should it be nothing? What do you think?
I guess it depends really on primarily on size. Motivations for outsourcing are different depending on the size of your organization. So if you're, let's say two digits organization, less than a hundred, you want to outsource almost everything. If I go to nontechnical parts, you want to outsource billing. You don't want to do billing for your company. You want to outsource even HR, right? Because simply there are too few of you to manage anything but what is the corest of the core of business. Then when you're getting bigger and bigger, then I think that the motivation changes and one of the factors is can I do that just as good or better than if I would outsource it? And the other one is price. Now price, I think, is a bad motivation. Everybody wants to be cheaper. I want to pay less for more. Everybody does. That's a normal thing, but that's a slippery slope to me that leads to hundreds of thousands of people being outsourced with the criteria of who is cheaper. So I'm going to ignore that for now. But there is that expertise level that really, really matters. I think that everybody should go cloud. And to me, the motivation for cloud is not really being cheaper than on-prem. It's about having capabilities that would be extremely difficult, extremely expensive to make with the low chance of success to get to the same level. Doing yourself what you would get if you use AWS would be close to impossible for 99% of companies. So it's expertise, I think, or solution that is the motivation when you grow bigger.
But even one of the items that you were saying is like, I could go AWS, Google, whatever. Doesn't matter. But the thing I'm focusing on right now is a managed solution. If I'm in AWS, I could spin up my own Elasticsearch cluster using EC2 instances, or I could use the Elasticsearch service. This is a conversation I've had with a lot of people. It's like, well, I'll just create my own because I don't know how their service works. I need to know exactly everything, how it works. And the argument is no, you don't really need to know how it works.
I have a difficulty to really distinguish if you're talking about SaaS now or a cloud, or what so not. I have a real difficulty distinguishing what is managed and then what is not managed. Like I could argue that if you it's spin up Elasticsearch in AWS yourself, that is still somehow managed, right? I mean, those VMs are managed by somebody. You're getting a managed service. It just depends on the level of the service because you are not managing really VMs. You're creating autoscaling groups that are managing your VMs when they fail and what so not. So, I guess it's about the level of managed that you want or need. Now, of course, if you go for Elastic directly and let Elastic do Elasticsearch for you, then you're getting more of managed something cause they're building their layer on top of AWS or whereever they're using it.
I guess I am going towards, what is the level of managed you want? Because the more managed you want, the more you pay and rightfully so.
Then it's like a calculation actually whether and I think that this is a tricky one. Let's say that you can pay AWS for VMs and what so not and then spin up Elasticsearch. You could pay Elastic that will incorporate the price of AWS for their nodes and build on top of it and on one hand. But then when you calculate how much that costs, compared to alternatives. I think that people are somehow forgetting the part of how much less work you're going to do and how much that costs. How expensive it is really to run Elastic in your on prem. And I'm not saying that it's cheaper or more expensive to run on prem. I'm just saying that you need to calculate that. Depending on the size, you might need one person dedicated to that depending on how big that is if it's a big Elasticsearch. Let's say half a person. How much is a half a person? Is that like a $100K a year?
Whatever it is, but that half a person is not going to be available 24/7.
If it's a half person. Well, it's a half person over 40 hours. That means they're only going to dedicate 20 hours a week to it. Well, that's only 80 hours a month. There's 750 hours a month. You're only talking about 10% of the coverage for that system.
But that's also kind of tricky, right? Because let's say that you and I'm keeping Elasticsearch just as example. You have a managed Elasticsearch. Does that mean that nobody in your organization needs to be on PagerDuty about that?
No. Somebody in your, somebody should be, but that's a push notification at that point. And I'm not having to sit in the ugly data center, watching dashboards.
Right. That's that's the, it's how, yes, you're on call. But then the only time you would actually go on the clock is if you received a notification. But that also means you have to be aware of how the systems work. And that gets me back to if, or, and we'll do it this way. Let's say you went directly to Elastic and you went with Elastic Cloud. You didn't roll your own on AWS. You didn't use the AWS flavor of Elasticsearch service. You went straight to Elastic because you figured they're the ones that maintain it. I might be paying a premium for it, but they in theory know what they're doing. So I'm willing to pay them more money.
Yeah and it's not really your business.
It's not my business. Yeah.
that's important part of the equation. Does it, you not having deep knowledge about Elasticsearch, does that help you really be better?
Well, it, so it depends on who you are. If you are the technical person, the answer may be yes to where you're building your resume item. If you're a business person, the answer is a hard no, because all you're wanting to care about is you're using Elastic for dashboarding. Some sort of observability. Observability is the new dashboarding, I guess. It's what is your role? And if you're trying to build up your resume or for the Europeans, your CV, I don't understand the whole CV thing. That's another conversation. If you're trying to build up your resume, then why are you still working at that company? Go work for Elastic.
Maybe Elastic doesn't want you.
Well, that's a possibility, but what should you outsource? You called it out at the top. From the business side, HR, payroll. All those things. Do it. Those are simple. If your team is five people, you're going to be outsourcing almost everything.
Yeah. I mean, small companies I think that should be a no brainer. Outsource everything except core of the core. But I still have my reservations when you're big, because if I would play now devil's advocate. And I think that I tend to lean to the other side, but I'm going to go against myself now. If you're talking about hundreds of people or even thousands, then I could make an argument that hiring one expert. No. Hiring three people who really, really, really, really know what they're doing with Elastic might be better than using managed Elastic, assuming that your size is so big that that makes sense financially, because there is always the thing that I do love managed services, but then sometimes when you might be so big that actually what you need goes beyond the managed service. I need it tweaked. I need it so special for my business and let me stress that there is like 0.05% of those who are really there. I'm talking about Netflix's of the world and then you might. But those are the cases. And now I know that there will be somebody listening saying, yes, we are special. We are a bank or we are this or that. And let me clarify. That's not what I mean. What I mean by special, I mean, you're so special and so good that you can even build your own software instead of third party. You can build your own database that will be better than whatever is there on the market because you can. Because you're Google.
I would even go one step further. Every person in your company is a full time employee. You have zero and I mean zero contractors. Zero. Because bringing people in as a contractor is a form of outsourcing.
Now that makes to me no sense. Absolutely no sense to be honest. Saying I don't want to outsource to Elastic. I'm going to outsource it to some random company who is going to manage my elastic. That I cannot understand. That defies the logic if you ask me.
Yeah. Let me rephrase what I just said. I am not anti bringing in contractors or consultants. But if that contractor or consultant is coming in for more than a term of maybe three or six months to get you ready so you can run your own system internally, then it's still the same problem. If you're bringing in somebody to let run your system for the next 16 years, that's the problem. That's, that's where it falls apart. Bringing somebody in to help you get up to speed and help enable and train and get people going. Okay, even if that takes 12 months, that's fine. No big deal, but to bring them in as the longterm solution, that is outsourcing. Now, the question is, and that's okay. Then you have done a managed outsource, even if it's on prem. That's okay. But that's. You can't say at the same time, well, we don't outsource anything because you obviously are.
I mean that's effectively a managed solution, right? Because if you say I'm going to go even higher than that. If you say I have this company where I employ, where I actually contract a hundred random people to manage my data center because I don't want to let AWS manage my data center, that's the same thing. It's exactly the same thing.
It's just because you're unwilling or unable in some legitimate cases to go to cloud.
Yeah, but you know, those excuses are really getting thinner and thinner with the day. Especially now that we know you can get Azure something in your on prem. You can get AWS, whatever they call it on prem and Google. You can have mixed one. There are so many options now.
And, and the, the big providers are providing gov cloud in some way, shape or form. So government's going in there. So if you're telling me that government can go to cloud and you can't,
who am I here with at that point? It doesn't make any sense. The question that we stated was what should I outsource to a managed solution might need to be changed into what shouldn't you outsource to a managed solution? What are the things that we should not outsource?
Things that differentiates your business from competitors business. Because if you outsource, then you cannot truly build a differentiator by outsourcing. And when I say outsourcing, outsourcing, managed something, right? If your business is a database, you cannot use Elastic, because you're no different than Elastic then or anybody else. Whatever your business is, you cannot outsource that. And just to clarify, I have a radical stand on that. When I say you cannot outsource, I mean, literally it needs to be in house. It cannot be third party company. It cannot be managed solution. It cannot be any of those things. It needs to be your employees directly employed by you for differentiators. Let's say you're a bank. You think, and I hope you do, that your core business today is to provide application payment mechanism or application that where people can consult their account. I'm inventing use case. If that's the differentiator, you need to build it yourself and it cannot be HCL. It cannot be Cap Gemini. It needs to be you.
Okay. Everybody just turned off what they were listening because that just put a lot of people out of business.
No, so, but that does not mean that there is no business for Cap Geminis of the world. There is, but not for what is the market differentiator for a simple reason, because that same person that is working for you could be working for somebody else. That expertise is not in your house. Some other bank can go to that same company and say, Hey, I want just as cool or better application than those guys and they're going to build it for them. There is no way to prevent other companies not being as awesome or more awesome than you are if it's not you who is doing that. It's very easy. Let's say that and I'm going to stick with the bank. If your differentiator is for example, how well you buy and sell on the stock market or whatever banks do outside of a private person's accounts, you're not going to outsource that. Right?
You would think so?
I hope you don't.
Well, let's just say that it does happen. It's very bizarre. Financial industry is very bizarre in general. But the point being made is what should you not outsource is what is your differentiator. It has to be if this is what your business is and you're outsourcing that, then you don't have a business.
If your business is not your business, then that's kind of linguistically correct to say that it's not your business.
It gets twisted and turned and it's like, okay, what are saying? Well, what we're saying right now is outsource everything that is not core to your business and I'm going to take it one step further. Outsource everything to a managed solution that is not core to your business. Going back to the Elastic thing. It's like, great. I need Elastic. Well, let's just go to Elastic, pay for Elastic Cloud, move on. If at some point Elastic Cloud starts to fail you then guess what? It's now becoming part of your business. Not fails you in a bad way, but it's now reached a certain level to maybe it's they've called you up and it's like, Hey, we're actually shutting this service down. Okay. Well that's one, one way. That happened to me. We're shutting the service down, so you need to migrate off. You've got six months. Okay. Obviously that's becoming part of your business in that moment. That doesn't mean you might not find a competing solution and you go to the competing solution and now you're back to fully managed outsource, but that gives you the opportunity to think, okay, well, do we want to own it? And if the answer is no, then I have to find a managed solution. If I do want to own it, then that means, okay, I'm managing part of it myself.
You know, if the managed solution that you're using is about to get shut down, that can mean one of the two things. Either it's being shut down, but it is potentially used by many and then somebody else would pick it up. Somebody else will provide that same service and if nobody else provides the same service after it was shut down, that means that actually you bet on a wrong horse and they just did you a favor.
yep. They forced your hand and now you have to leave. And if you keep on pressing towards that point of, well, this is how we did everything. This is what we bet the farm on. Well, you bet on the wrong farm.
Which happens. It happens all the time. I'm ashamed of how many wrong bets I've made. I mean, not ashamed. It's a learning experience always.
Yes. What did that make possible for you when you made that wrong bet? You learned what not to do.
Not only that, but you learned the basics of what successful successors of that solutions are using. If you were so good that you bet on Mesos, when it was all the rage that gave you such a good base for Kubernetes and Swarm. If you learned Swarm that gave you a very good base for Kubernetes. So betting on a wrong horse just means that the implementation was not the successful one or adoption, but the underlying principles are hardly ever die that fast.
What can we tell people that say, there's no way I can outsource anything. This is a company that this is completely internal. Everybody's a full time employee, zero contractors. We cannot outsource anything.
US government is probably one of the most outsourced things that exists.
Yeah. But if US government can run on cloud, which is managed solution or part of the solution, right? To be honest until 15 minutes ago, I didn't think about it in those terms, but I don't know how it didn't click before, but when you said it, it, something clicked in me. If US government can run on cloud, then I cannot imagine who can not, from the perspective of we have those things that we need to comply with. We are physically prevented and all that stuff, and we know I'm not gonna name names, but we know that banks, for example, which is usually financial institutions that are usually quoted as we cannot do that, those things. We know that there are some of the biggest banks in the world are going to managed solutions. Whether when we say go, that ends up being 0.5% of the workload or 20%, that's a separate story, but that move is happening. Accomplishing those 0.5% of being managed is the critical part because after that it's snowball effect. After that, it is easy, because you have a precedent you can quote.
Yeah. And you know exactly what the process is at least one process was to put it that way to get something within your four walls to a managed service provider or to a managed solution, not service. Managed service providers are a bit different than managed solution because that flavor is just a little bit different.
The real issue I think is that if you're speaking about bigger companies, is that on one hand, you cannot do big bang and say, I'm going to have a project that will transfer everything I have to a managed solution, right? That's never going to happen. That would be 700 years of work. Right. On the other hand, there is a real big challenge with close to no benefits of moving part of the workload to a managed solution. Let's say you're a big company. You have everything on prem and you choose to use Elastic Cloud. That's not going to be good. I mean, if no other reason the latency between you and Elastic and 57 proxies and VPNs and what so not in between, and firewalls is going to make that a worse solution than what was there before and that's I think a real challenge. I'm not saying it's undoable, it's doable and it's everybody's should do it, but picking the right thing to be the first one to move, to be a managed solution is the real challenge. Or we can say change the subject from Elastic. I don't know, Datadog right? You will be streaming metrics somewhere outside your organization. Let's say that you're convinced that that's safe and there is no nothing confidential. So still it's going to be slow.
Because your pipe outbound from your data center, sitting outside your corporate headquarters. I can think of two people right now in the area I live in. That's exactly how they're set up. The data center is setting right beside the corporate headquarters, like they share the same parking lot. To have number one, you probably don't have multiple routes coming in, so therefore you don't have multiple egresses coming out of your data center. If you do, your networking people were dumb and they used the same provider on both of the egresses. That makes no sense. Oh, by the way. You're saying you don't send, you don't outsource anything. Do you have a network provider? You outsource your network.
Everybody outsources. It's contradictory. I don't want to outsource, but I outsource type of stuff, but still it is a huge issue. And then if we continue with the example you were just mentioning and I started before then you might easily come to conclusion that you need to make a heavy investment in your current on prem for you to use a managed solution. And that becomes then contradictory as hell. Let's say the latency is killing you between Elastic Cloud and your data center. Are you really going to invest a lot of money in removing that obstacle, knowing that you just decided to have less on prem?
Yeah, there's no way. Let's say you had your outbound was a gig. That means you had, now you have to go to a 10 gig pipe outbound in order to support everything. That is not a linear cost, by the way, to go from one gig to 10 gig. If you believe you cannot use a managed solution, that may be true. And what Viktor was just saying, if you're completely on-prem and you don't have the kind of bandwidth to ship things outside the four walls, then it probably doesn't make any sense and you're going to be stuck having to run everything in your data center. Oh, by the way, you're gonna be buying more hardware, which means you need more power, more cooling, more everything else versus get everything outside. In fact, we read a post about this on the livestream a few weeks ago to where Microsoft's underwater data center resurfaced. And it was highly efficient. Who would have thought you would have had your server racks running underwater? Would you invest in that? No, but Microsoft did. And guess what? It's cheap.
Because that investment is too big for any single company. But Microsoft is sharing that investment with many companies. I mean, not sharing directly, but kind of they're a provider of more than one company. They can do that. You cannot. But there is still that problem. It's almost like being in jail, right? You cannot go out. So you need to make more offenses while you're in, and then you will not be able to go out for even longer because you can easily come to conclusion, I cannot go to cloud, let's say, or managed service or this or that, and there are 57 reasons why I should, but I cannot. So I will invest more in my own stuff. And then there will be not 57, but next year they will be 117 reasons you should go, but still even bigger number of reasons why you cannot. As time passes. It's just more and more complicated, not less to do that and more and more reasons at the same time why you should do it.
If you're in this situation today, or if you're working for a company that is in this situation today, unless you're about five years from retirement, I would say move on because the world is leaving you behind. Even the US government is leaving you behind.
That's one of the things I think we discussed quite a few times. That is that, there is a huge difference between you having vested interest in company and when I say vested, that means significant shares in a company, and you're getting a salary in that company. If it's the latter case than what you just said makes perfect sense. Go where you're going to get better salary. No, sorry, not very going to get better salary, but go where you're going to get better CV that will give you a better salary. But then if you have a vested interest, you know, to be honest, if I would have a million dollars in shares in a company, I would never leave that company. Uh, unluckily for me, I don't have a million dollars in shares in any single company.
I understand where you're coming from there, but if I had a million shares, a million dollars in shares of Enron prior to it blowing up, it doesn't matter, right? That's I'm saying that even if you have the shares, that is no guarantee that the shares are going to be worth anything when you're ready to exercise them.
But that's the thing. I could bet that majority of people who had significant shares in Enron did not realize what will happen until it happened. We're all lying to ourselves in a way or thinking that it will be different or what so not. Nobody realizes that. You know, I know that for example, and I know this from personal experience, many of the normal employees in Nokia knew what's coming, but almost nobody in management knew what's coming. Whether they chose not to know or whether they were oblivious or what, what was the reason is different. When I say Nokia, I mean, Nokia part of that was doing smart phones, not telecommunications.
Yeah, because they could see it from the bottom up and the top down didn't see it.
Yeah, because they see it through different means. They compare the products, I think, and experiences while XX compare numbers and numbers can change overnight. It was enough for Nokia to have an event where Steve Jobs appeared on the scene to destroy it overnight. Literally overnight.
Yep. One more thing and then there was the iPhone in 2007. That was it. Or 2006. I don't remember when they introduced it now,
Yes, something like that.
Okay. So if you are not outsourcing, you should figure out why not. If you think you're not outsourcing anything, you're deceived. Something is probably being outsourced. And if you are working in a place that there is no true outsourcing, but you're only a couple of years away from retirement, just stay there and retire and go on about life unless the company's name is Enron, then get out now. If you don't know who Enron is, go look it up. Okay. That's our take on what should be outsourced to a managed solution. What do you think? Let us know.
We hope this episode was helpful to you. If you want to discuss it or ask a question, please reach out to us. Our contact information and the link to the Slack workspace are at https://www.devopsparadox.com/contact. If you subscribe through Apple Podcasts, be sure to leave us a review there. That helps other people discover this podcast. Go sign up right now at https://www.devopsparadox.com/ to receive an email whenever we drop the latest episode. Thank you for listening to DevOps Paradox.