Subscribe
Copied to clipboard
Share
Share
Copied to clipboard
Embed
Copied to clipboard
The Business of Open Source
Trailer
Bonus
Episode 18
Season 1
Cloud-Native Considerations for SMBs with Apurva Joshi
The conversation covers:
- The difference between cloud computing and cloud-native, according to AJ
- Whether it’s possible to have a cloud-native application that runs on-premise
- The types of conversations that AJ has with customers, as VP of product. AJ also talks about the different types of customers that DigitalOcean serves.
- How the needs of smaller teams tend to differ from the needs of enterprise users — and the challenges that smaller teams face when learning and implementing cloud-native applications.
- Making decisions when using Kubernetes, and how it can be overwhelming due to the sheer number of choices that you can make.
- Some of the main motivations that are driving smaller companies to Kubernetes. AJ also explains what he thinks is the best rationale for using Kubernetes.
- Popular misconceptions about cloud-native and Kubernetes that AJ is seeing.
- Why customers often struggle to make technology decisions to support their business goals.
- AJ’s advice for businesses when making technology decisions.
- Why startups are encouraged to start by using open source — and why open source wins in the end when compared to proprietary solutions.
Links
- DigitalOcean: https://www.digitalocean.com/
- Twitter: https://twitter.com/apurvajo
- LinkedIn: https://www.linkedin.com/in/apurvajo/
Transcript
Emily: Hi everyone. I’m Emily Omier, your host, and my day job is helping companies position themselves in the cloud-native ecosystem so that their product’s value is obvious to end-users. I started this podcast because organizations embark on the cloud naive journey for business reasons, but in general, the industry doesn’t talk about them. Instead, we talk a lot about technical reasons. I’m hoping that with this podcast, we focus more on the business goals and business motivations that lead organizations to adopt cloud-native and Kubernetes. I hope you’ll join me.
Emily: Welcome to The Business of Cloud Native. I'm Emily Omier, your host, and today I'm chatting with AJ. AJ, can you go ahead and introduce yourself?
AJ: Hey, I'm AJ. I’m vice president of product for DigitalOcean. I've been with the company for about 15 months. Before that, I spent about a couple of decades with Microsoft. I was fortunate to work on Azure for the last decade, and I had the opportunity to build some cloud services with the company.
Emily: And thank you so much for joining us.
AJ: Thank you, thank you for having me.
Emily: I always like to start out by asking, what do you actually do? What does a day look like?
AJ: [laughs]. It’s an interesting question. So, yes, the day is usually all over the place depending on the priorities and things that are in motion for a given quarter or a week, per se. But usually, my days involve working with the team around the strategic initiatives that have been planned, driving clarity around different projects that I [unintelligible]. Mainly working with leadership on defining some of the roadmap for the product as well as the company. And yeah, and talking to lots of customers. That's something that I really, really enjoy. And every other day I have a meeting or two talking to our customers, learning from them, how they use our products and how can we get better.
Emily: I'm going to ask more about those conversations with customers because that's what I find really interesting. But first, actually, I wanted to start with another question. What do you see as the difference between cloud computing and cloud-native?
AJ: The difference essentially, in a way, the cloud computing is a much bigger umbrella around how we as a technology industry are enabling other businesses to bring their workload to a more scalable, more efficient, more secure environment versus trying to host, optimize, or do things by themselves. And the cloud-native, in a way, it's a subset of a cloud computing where not necessarily you always have to have existing workloads or something that is prior technology that has been already built and you're looking for a place to host. In a way, when you're building something out, new, greenfield apps and whatnot, you're starting from scratch, you're building your applications and solutions that are cloud-native by definition. They're built for Cloud; they're born in Cloud, and are optimizing the latest and the greatest innovations that are present and as future-looking to help you scale and succeed your business, in a way.
Emily: Do you think it's possible to have a cloud-native application that runs on-premise?
AJ: There's a lot of [laughs] innovations happening in pockets, and especially from the top providers to enable those scenarios. But at the end of the day, those investments are essentially driven to help people and companies, especially on the larger scale, to buy some time to completely move to the public cloud where the industry takes their time to come up with the compliance, security requirements and [unintelligible]. So, you'll start to see—you might have heard about some of the investments these top cloud providers are doing about allowing and bringing those similar stack and technologies that they are building in a public cloud to on-premise or running on their own data center, in a way. So, it is possible, in bits and pockets to start with a cloud-native to run, on-premise, but that customer segment and the target is very, very different than the ones that start in a public cloud first.
Emily: I want to switch to talking about some of the conversations that you have with customers. I really like to understand what end users are thinking. What would you say when you talk to customers? What's the thing that they're most excited about?
AJ: Right. So, it depends on what segment of customers you're speaking with, right? DigitalOcean serves a very different set of customers than a typical large cloud providers do. We're focused more on individual developers, small startups, or SMBs. Again, when I say SMBs, it's a broad term, when I say SMBs the S with [unintelligible].
So, we focus mainly on two to ten devs team, and smaller companies and whatnot. So, their requirements are very different; their needs are very unique compared to what I used to talk, back in my past life, with enterprise customers. Their requirements are very unique and different as well. So, what I hear from the customers that I speak with recently, and have been speaking with for last over a year, is how can I make my business that is [unintelligible] on a cloud? And what I mean by that is how do I build solutions that are simple, easy to understand, and where I'm focused on building software and not really worrying about the complexity of the infrastructure, at the same time, keep the price in control and very simple and predictable.
And that resonates really, really well. The tons and tons of customers that I spoke with recently, they moved from large cloud providers to our platform because their business was not viable on those cloud providers. And what I mean by that is you because of the complexity of how the [prime systems] product offering and the sticker shock they get, at the end of a month on a bill, it just does not make any business sense for them to keep on running on that cloud. So, they're looking for that kind of simplicity; they're looking for price predictability; they’re looking for something easy to get started, and cheap so they don't break the bank. I mean, those are some of the real common themes that I keep hearing from the business side of the customers, SMBs.
Then there's a set of different customers that I speak with. They are individual developers, they are students, they are people who are trying to learn technology. And what DigitalOcean has done great for our last eight, nine years is not only build this platform but build this great community of people who come to learn about technology. I would say more than 50 percent of our customers tell me how they love DO and they found DO because they were trying to learn so-and-so technology and they came and hit our tutorials. And they got to know about the company from the tutorials, they started learning, and it was very easy to transition to move into the platform because that's something they absolutely love.
Emily: When you think about the needs of these smaller teams, how would you contrast that with the enterprise users that you used to talk to more?
AJ: Yeah. Their needs are very different and very unique. They just need bare minimum basic things to get started with their application. They want to avoid all these complexity of hundred-plus services and trying to make the decision, which is the right one, which is the wrong one to go ahead with. So, they're not really looking for all kinds of bells and whistles and security requirement, or that feature that only one out of hundred customers will need or whatnot.
They're just looking for very minimum kind of a solution from the technology perspective. Something really simple, really easy to start with, not too many options out there that causes more confusion versus getting started quickly. So, simplicity is the biggest aspect that I see from this customer segment. And then second on the simplicity side is also simple pricing. For example, they would love to build applications and deploy and across the world, [across] regions, or [unintelligible] more regions to target different segments and customers. And they want to have the same pricing.
And bandwidth pricing is a great example. If you look at the other cloud providers, you end up paying different bandwidth pricing depending on which region you're deployed on. Unlike DO where the bandwidth pricing is flat across the world. So, that's really appealing to the customer set. Same thing goes with another product like storage, where you store your data, and when you are accessing the data, you need the predictability, you need to know how much it's going to cost you as your end-user usage pattern changes.
If you look at the top cloud provider, if you store your data in their storage, they will charge you for storage they will charge you hot data cold data, different API calls, you know, API calls for seconds and whatnot, and by the end of the day, your bill is very unpredictable compared to what you see at DO where you pay a flat monthly price, and none of those complexity comes in. So, that is a unique change that I see. And then, again, their requirements are very different, very, very simple. They don't need all the complexity. Something really simple to start with, including pricing.
Emily: This is interesting because most people, or… I should say, I. When I think of cloud-native, and I think even of cloud computing, simple is not the word that comes to mind.
AJ: Right.
Emily: How frustrating is this for these smaller teams to try to wrap their head around everything that they need to learn and understand in order to successfully use cloud-native applications?
AJ: It is very frustrating. And Kubernetes is a great example. It has a huge mindshare in the industry. It is a hugely popular technology that everybody's moving towards because it's the next big thing and the cool thing out there in the market, but the reality is something really, really complicated to learn, to understand. So, it is a super frustrating for people to not only learn the technology that is new and complicated but at the same time trying adapt to different versions of the similar implementation across different cloud because they were built to solve for a few specific customers in [unintelligible] that might not be suitable to them.
The one thing that I keep on hearing from the customers that are using our Kubernetes, they just love the fact how vanilla Kubernetes is offering it is. It's not too many bells and whistles. They have to really understand what this now means or what that now means, versus just, I understand the basic concept that I read from the tutorials, and I get what I'm seeing there. So, it is frustrating, at least on the cloud-native side, and the more layer of abstraction that you provide and make it simple, the onboarding becomes really, really exciting for them. But to my [unintelligible], to provide this simplicity to our end customers, we have to take on a crazy amount of complexity on our side, on the back end, and on the infrastructure. So, it's even more frustrating for our engineering to make sure they are delivering on the product requirements that my team comes up with because we want to keep things simple and straightforward for our customers.
Emily: A lot of people think one of the advantages of Kubernetes is being that it's infinitely extendable; it's infinitely flexible. And yet, obviously, when you have, sort of, infinite options, that means you have to make a bazillion different choices in order to just get something to work. How do your customers tend to approach those trade-offs? Do they want somebody to make the decisions for them?
AJ: Right, right. And that's a great question. Again, this is a very different customer in that respect. And there's a saying that I have in my team that I tell my team, “Be careful what you measure because that drives behaviors.” So, now that we are targeting a very specific set of customers, the scale is not the biggest priority on their mind at any given time, because they're building, they're prototyping, they're starting something small, and they're growing with this.
So, that's not something that they want to over optimize. It goes back to the point that I made: they want solutions that are more vanilla. But when you compare these concerns that you talked about, with the large cloud providers, they are real because their needs are very different. They're looking for a solution or Kubernetes clusters with more than thousand-plus nodes, and things along those lines. And to support that and to support those scenarios, yes, the complexity comes in by nature, and they have to build certain features and solutions to work around those limitations.
And that’s where things starts getting complicated because it's not a one size fits everyone scenario when you have these vast variety of customers coming in and trying to use the product that you build that was essentially built based on the feedback that you get—getting from your largest, and the biggest, and the highest paying customers. Goes back to the point that I made: be careful what you measure. Biggest thing that they measure based on the top cloud provider is the how many big multi-million-dollar deals are we getting? And those customers have very unique needs. Every customer will have a different feature requirements and sets, and if you rally around that, you end up building your product, by definition, that's complex.
Emily: When you're talking to your team about the conversations that you have with customers, what do you feel like is sort of hard to communicate? And I'm talking about when you're trying to translate, almost, these customer needs to your own technical team.
AJ: Yeah, I don't deal with—on a day-to-day—execution side of things, so I stay away from translating these requirements to my product team or engineering team. Instead, I end up introducing those guys to the customers and have them talk to them directly because nothing beats talking to the customers directly versus me getting the feedback and trying to relay the same to the broader team to go and build this product out. So, it's a big part of our DNA, it's a big part of our culture, on inviting customers, talking to them more frequently before we build anything. That works out. The learning that I get from talking to our customers is around defining the strategy and the vision for the company on who we want to do and who we want to be in two years, three years, or four years from now.
Emily: What do you see—for these smaller teams, smaller companies, what is the main motivation for using something like Kubernetes?
AJ: Yeah, it goes back to the point that I made: there's a huge amount of mindshare. So, you know what, you end up finding quite a bit of customers, they just want to use it because it's the buzzword, and then that's where they start. And the second motivation where the people who really, really know the technology, and know what it can do is to avoid the infrastructure management piece they had to deal with themselves around what happens when the—you know, once your machine goes down. How do I add certain things into [unintelligible]? How do I bring certain security isolation?
All those the orchestration piece that Kubernetes gives you by definition is very empowering to them to go and offload some of the manual work they used to do. The third tangent that I'm seeing, at least with DO and the customers that I speak to, that it’s a great platform and a cheap way for them to start learning about the technology because learning is a big part of what your customers are, right? So, as they learn about technology as the buzzword [unintelligible] Kubernetes keeps on getting hot, they come running into the documentation that we've created, they love that. And then they come in, spin up the clusters just to learn what this technology is. I've had some customers that are really, really large enterprises, but a smaller team within those enterprises, they're sending their dev teams to DO saying, “You know what? Great platform. Go learn about Kubernetes and see how the technology works because that's the easiest and fastest way, and the cheapest way to get that stuff done before you actually start using it.”
Emily: Do you think that most people come to learn about Kubernetes because Kubernetes is a buzzword?
AJ: Well, that's one part of it, right? There's one step, they’re trying to learn certain things, so you're seeing certain percent that they are just going for that mindshare they have. Then there is a set of customers who know what it is, and why they want to use it, and they are very thoughtful and mindful around what they're going to use that for. And that's where the SMB business comes in, or the more business side of the customer they come in, and to that point is where they just want to leverage and get rid of all the manual orchestration work they had to do with all these virtual machines that they had to be with. But then when you talk about the customers, you're talking about the customers who are dealing with those clusters of VMs. You’re not really talking about customers who's trying to just spin up a cluster with two or three nodes because that's the guy who's trying to learn.
Emily: And among your customers in particular, what do you think some of the misconceptions are, either about cloud-native in general or about Kubernetes specifically?
AJ: Yeah there's not really a misconception perspective. We… the conversations that I ended up having with them is not about the philosophy of the technology that has been evolved across us. I mean, obviously DO didn't invent the Kubernetes, or neither did Microsoft, so when you stay away from that conversation [unintelligible] that sort of conversation.
But the biggest misconception is that this is the way for me to build the cloud-native application because that's what the industry tells me to; that's what it looks like. So, some people go out and start their [unintelligible] applications on the top of Kubernetes thinking that's the only way; that's how I should do it, whether it really fits the bill or not. The reality is there might be and should be using some sort of a PaaS platform. They might be using some sort of a container solution that is a full-blown PaaS, and they don't really need the Kubernetes clusters. And that's where the misconception is, is because they just struggle making the right technology bets for the solution that they're trying to build and drive versus just catching on to the latest and greatest buzzword or the technologies that are being out there.
Emily: Why do you think this happens? Why do you think customers sometimes struggle to make the right technology decisions based on their actual business goals?
AJ: Because that's a really [laughs] hard problem to solve, at least when you're trying to build a business, you're not always ends up being the technology business. Technology does not all end up being your first [unintelligible], or the biggest skills set that you have. They’re just trying to pick and choose what is being influenced by the learning, or through forums and whatnot to go along with. There's hardly very few customers that I end up seeing, they make the technology decisions that are long term with the scalable solutions, and right coding language, and whatnot. It's mainly around what's the best and the latest that I can get my hands with? What I can learn quickly about? What are the resources are available? And let me start prototyping that fast. And soon.
Emily: What advice would you give to these businesses? Like, maybe they're not going to make the perfect technology decision, but if you have advice to maybe help them make a better technology decision, or just what to think about to try to improve that decision making process?
AJ: You know, I get that question asked quite a lot from people who are trying to start something new. And the right advice there is to focus on job to be done. What is the end goal that you're trying to solve for within a few weeks or a month, or maybe a quarter? What is the job to be done? And then look for various skills and comfort-level are versus trying choose for what is the latest and greatest and then spend a crazy amount of time trying to learn that technology because you don't have that skill set in-house or within you.
So, start with what you feel comfortable, where you have the skill sets, where you can make and prototype something quicker and sooner, but while keeping the core job to be done in the mind. And if the job to be done is not really technology-focused, it's solving some different business problem, then don't heavily pivot on picking the right technology.
Emily: Would you say this also sort of starts with an honest evaluation of what your… resources so to speak, what your skills are?
AJ: One hundred percent. That's the question you have to ask yourself as well. So, if you're comfortable with one coding language, go with it. Just don't go pick the latest and greatest coding language because that's the biggest buzzword, but then you end up finding yourself spending quite a bit of time learning that technology, but you're not really solving for the job that you [unintelligible].
Emily: What do you think are the best rationale that you see for using Kubernetes?
AJ: It's again, goes back to, in my opinion, Kubernetes is still infrastructure. People end up confusing that with the layer of platform as a service, and whatnot. The real rationale in using that technology is to optimize for some of the manual work you used to do around managing infrastructures and VM on a scale. SO some of the OS updates, the auto-upgrades, and what happens when the VM goes down? How do you add more VMs to your existing network and whatnot?
Those were very lengthy and time-consuming task, and all the orchestration pieces that Kubernetes provides, it's a great way to start and manage your existing infrastructure. I mean, that's the way I would recommend people to tiptoe into the technology, and that's where the majority of the customers are. Then there's a set of customers who are looking to build an high-level PaaS offering or a Software as a Service offering. These are more skilled people with the right talent and enough money to invest in the right place. Kubernetes is a great platform for them to build those sort of PasS and SaaS offering on top of that because it does not make any sense in trying to build those custom orchestration when you are building a solution that's going to serve tens of thousands of end-users and going to scale [unintelligible]. So, but those are pretty low percent of Kubernetes users, and that's where the industry trend seems to be, also, growing around people building larger businesses.
Emily: What advice would you have about making these longer-term technology decisions? When you first started talking about making good technology decisions, it was about what are we going to do this quarter? What about when you're thinking, “What are we going to do in the next two years? What are we going to do in the next five years?” How far out should you be thinking when you're making a technology decision?
AJ: Yeah, that's a pretty hard situation to be in. And not many will be trying to answer that question, especially the ones that I deal with, the customer segment that I'm talking about. On longer-term technology decisions, it's a very different set of customers who are building solutions for a larger customer segments and whatnot. The advice, again, remains the same. Start with something that you are comfortable with, keep an eye on what is the game plan is going to be when you start hitting a certain scale and keep an eye on your technical debt.
Again, you don't want to keep on piling on to technical debt for too long in trying to build a solution. So, whatever that you design, just make sure you have the capability, and you're choosing the technology that's going to be around and evolve when the time is right for you to go out and start paying your technical debt. The second aspect, I would ask them to invest in quite a bit of automation; investing quite a bit of work that it's not really sexy per se. When you're building features and writing code, building new features and designing the new product ideas is always fun, but then there's a workaround certain things on automation. There's always this one guy who does all these CI/CD automation, pipeline automation, making sure your code written a certain way, and those things; those are very critical investments.
If you do not make them a core part of your development process from get-go, you're going to have a really hard time in two years, or three years, or four years from now to keep up with what's going on and to keep up and automate all that code in the application that you wrote to scale with the business that is scaling.
Emily: What advice specifically do you have for startups? So, not just small companies; small companies that are looking to scale quickly. Do you think that there's any difference in how you recommend adopting Kubernetes or cloud-native versus, say, a small company that's not planning to scale massively in the next couple of years?
AJ: Yeah, I think the latter question is, is really even if you were to ask the founder of the company, she wouldn't be able to answer that, “We're not planning to scale that fast.” The scale comes; it surprises you. [laughs]. When it was about product-market fit, you're going to find the scale and that's going to happen. My recommendation is at a more generic level.
If you're starting something new, you’re building up from scratch, start cloud-native. Pick the right technology that are evolving, and start with open source because you're going to have the wave of innovations coming in. Why open source? They will outweigh trying to use something proprietary or trying to reinvent the wheel yourself. So, if you starting something new, start cloud-native, use open source. It allows you to quickly iterate and build things faster. And you benefit from a larger community contribution coming into those innovations. Like, at the end of the day, I like to say this, regardless of what proprietary solution you use or who you are and whatnot, open-source wins in the end.
Emily: Why do you think open source wins in the end?
AJ: It's because the larger community and multiple minds are working, trying to solve a similar problem. It’s far, far—much better. It's more inclusive. It's not as opinionated as when you would be when you're building your own proprietary software or trying to do something to solve your one specific problem. When you're building products and solutions that are going to be used across the world by different kinds of customers, your segments going to change, you really want to make a bet on a technology and a solutions that are built by different minds, more inclusive people, people with different opinion and thinking from yourself, and in the long run, that pays up.
The great example I can give you from my past life is I was fortunate to build a Platform as a Service for Azure. Back in the days, there was no Kubernetes. But what we ended up building to build that technology was just a really big custom orchestration exactly similar to what Kubernetes is today. The reality is fast forward to, you know, eight, nine years from now everybody's talking about Kubernetes, not that custom orchestration that we built. The business is working; that is great, but at the end of the day, what won was the open-source orchestration that allowed people to manage thousands and hundreds of thousands of VMs on a large scale, and that's winning.
Emily: Would you recommend open source even for small companies that, say, don't have a lot of expertise in—
AJ: 100 percent.
Emily: —A lot of people say open source is free like a puppy, right? So, you have to invest a lot in—
AJ: No, no, it's 100 percent because it's really easy to get started with open source. It's really easy to get something that's out there. There's a bigger community to try and help you out, and it gives immense pleasure to contribute back to something that you're consuming as well. I mean, this is, by definition, is a human nature. It keeps you more engaged and innovative when you're starting there. So, I think it’s when you're prototyping something, just always try and go with the open-source. You're going to get tons and tons of ideas and levers you could pull. If you’re going to run into some issues, somebody has, somewhere, ran into that and will have a solution. So, that's the easiest way to start.
Emily: Anything else that you'd like to add, that really sticks out about the business reasons that people are choosing Kubernetes or cloud-native?
AJ: Yeah. Again, like I said, the business reason, you know, majority of them… more than 50 percent are pick that to start something new, and learn in their perspective, and just use the benefits of the custom—or not the custom, but the open-source orchestration to deal with their few virtual machines, they were running before, or whatnot. Then there is a trend that is growing around the Kubernetes ecosystem where people are now building more Paas and SaaS solution on top of that, and these are the people who know how the technology works, who are the people who are contributing back to the Kubernetes ecosystem as well. But there are a layer of abstractions that have come in on top of Kubernetes where problems that were created by the technology—some of the innovations that you see from Google, Axure, that providing you a bunch of bells and whistles to go build those PaaS and Saas on top of Kubernetes. So, that's where—now the reason why people are using that.
Emily: All right, AJ, what is an engineering tool that you couldn't do your job without? Or maybe I should say, what's a tool that you just couldn't do your job without?
AJ: [laughs]. Well, I'm an engineer at heart, but I don't code anymore. I mean, it's been a while, but so if there's one tool that I can’t do my job without right now, into this world is definitely videoconferencing. When everybody's remote. And DO as a company was 70 percent remote before the pandemic. Now we’re 100 percent, so if that tool’s gone away, there is zero productivity. So, that's the biggest one that I have in my mind. And besides that, things like Slack. We work, live, breathe that, and it makes things pretty useful. So, those are the two things I can do my job without.
Emily: How can listeners connect with you or follow you?
AJ: Yeah, they can follow me on Twitter or connect with me on my LinkedIn. Both handles are my first name and J-O. It’s apurvajo, A-P-U-R-V-A-J-O. You know, I always love to hear from our customers, and a future prospect or anybody who wants to learn about the company and what we have is always exciting.
Emily: All right. Well, thank you so much for joining us.
AJ: Likewise. Thank you.
Emily: Thanks for listening. I hope you’ve learned just a little bit more about The Business of Cloud Native. If you’d like to connect with me or learn more about my positioning services, look me up on LinkedIn: I’m Emily Omier, that’s O-M-I-E-R, or visit my website which is emilyomier.com. Thank you, and until next time.
Announcer: This has been a HumblePod production. Stay humble.