Cloud Crunch
Cloud Crunch

Episode · 1 month ago

S3E5: Data ecosystem around Snowflake & private equity verticals

ABOUT THIS EPISODE

With only two episodes left, today's episode is centered around “Data ecosystem around Snowflake & private equity verticals” We will focus on, "What are the areas where you are seeing strong adoption of cloud-analytics solutions at Private Equity companies, and "What are typical use cases for advanced analytics at PE portfolio companies? This conversation is led by our CTO of all things data at 2nd Watch Fred Bliss, and Director of Marketing Michael Elliott. We are also joined by our honored guest Paul Corning – Practice Director, Private Equity.

Involve Solve Evolve. Welcome to cloud Crunch, the podcast for any large enterprise planning on moving to or is in the midst of moving to the cloud. Hosted by the cloud computing experts from Second Watch, Michael Elliott, Executive director of Marketing, and Fred Bliss, CTO of all Things Data at Second Watch and now here are your hosts of cloud Crunch. Welcome back to cloud Crunch. This is Mike Wally, your host of cloud Crunch. Joining me as always is my co host Fred Bliss, CTO of All Things Data here at Second Watch. Welcome Fred hiaol No. And we have a special guest today joining us as Jesse Sam, Practice Director Application Modernization here at second Watch. Welcome Jesse to the hot seat. Thanks Michael. All right, I see for the audience. Can you kind of give a quick synopsis of your background. Sure. So, I'm a mechanical engineer turned programmer back when we still called them programmers, I guess, and pretty much self taught. Got in a bullpen with some really smart CS guys out of college at some startups, and I just caught the bug. I've been working in the field for probably twenty years or so now and progressed from that programmer level up through cloud architecture, and now I'm leading the practice here at second Watch that focuses on application modernization. Okay, so Jesse, you stole my line because we were all just programmers building these huge, monolithic applications. And you know, the term programmer has really evolved, but it's really the focus today is we'ren application development and how it's kind of evolved. We use the terms like app mog,...

...use the terms cloud native development kind of label this new world. So the question for you is how did we get here from the good old days to the micro service age that were were simple? I mean, you had a single programming language that wrote to a database and it did something. Yeah, that was easier, but also not scalable and not very performance sometimes as it grew larger and larger. But you're right, that was the architecture of the day because of a lot of things, a lot of constraints around hardware and networking, and it was just evolutionary step in how to write software. So breaking things apart isn't a new idea. Back before Amazon even existed Amazon Web Services, that is, people were trying to break apart these monolithic applications on prem into services. It went from RPC to x amount to now we're at Jason and some other specs out there. We've always tried to do better as software developers, and now with the advent of the cloud, service oriented architecture has turned into micro service architecture where you can deploy things much faster, much more isolation, separation of concerns, single responsibility principle. But it all comes to play and it just keeps evolving as the platforms do as well. What are some of the benefits that business users I guess organizations in general get out of this um you know, compared to how things were over the last twenty years or so. Features faster. From a business user perspective, ideally, the users of your application have no idea how it's architected, right, but if they see more features faster, fixes to broken features faster, they're going to appreciate that, right. And then on the back end and of that...

...from the organizational perspective, if we're talking about enterprise, I t the enablers for those benefits of the business user are the ability to deploy parts of the application independently and what that gives you is isolated change and really reduces the scope of a testing effort, for instance, and it really allows you to scale those individual pieces to meet the demands that the users are putting on the application. You know, going back to your comment around being able to deploy faster, you know, I remember the stories coming out of and I think it was what Netflix where they were releasing code, and we go back to my codebal days, we're releasing code once a month if you're lucky, they're releasing code every ten seconds or fifteen seconds or something like that. And I think there's a lot to be said around your ability just to be adaptive and reactive, not from the user perspective, but ultimately from an end consumer perspective or how you meet your business needs to react to your customers. So where I'm trying to go with that is you're talking a lot around the users from the perspective within the business, but ultimately, what we're trying to get to is create differentiation in the marketplace for our customers for their customers, if that makes sense, right. So, the same principles apply whether it's an enterprise application or whether it's a consumer facing application. Consumers want the features faster. They want bugs fixed faster, and it's that it's the DevOps philosophy applied to UH micro services architectural approach that makes that possible, UM, regardless of of e commerce or app on a phone or UH internal line business application. Those architectures...

...are supporting all of those things now, and all of those users want the same UH, they want a great experience. So let's talk a little bit about DevOps. What what does that term DevOps really mean? Not from a definitional perspective, but what it means for the business. What it means for the business is a philosophy applied to the software development process that results in UH massive amounts of communication between operators and developers of platforms. It means adopting agile principles as well as the DevOps philosophy to to provide UH high quality, isolated changes that can be pushed out with such confidence that, like you said, you can push them out every ten seconds. It's kind of funny because we see, um, you know, over the last ten years, the rise of DevOps has kind of put more responsibility I guess in some organizations onto the developer and given I guess a reason to no longer need that traditional system administrator. How do you see the role of the cysadmin and the developer you know coming together or you know, what are the different roles today versus UM where they were before. That pendulum keeps swinging back and forth, even even today where we some companies are empowering development teams with full stack responsibility including the cloud infrastructure, including support UH and bug fixes and like really making a small I T department out of the teams that develop these single micro services that are composed into the larger application. UM swing the pendulum back the other way, and we've got enterprises that want separate team that are handling the cloud infrastructure, separate...

...from the teams that are developing the software. I think it's gonna it's gonna swing somewhere in the middle where we have the concept of the operators of a platform that is UH, that is a separate skill set from developing applications that run on the platform. We can see that with Kubernetes today, where these micro service enabling platforms become require expertise to care and feed for these things. That has very little to do with writing the software that's going to run on on Kubernetes cluster. So the pendulum does keep swinging back and forth. But I think we're gonna land somewhere in the middle where there is a separation of skills, but they have to work tightly together, of course, because you know, that's the DevOps philosophy, and if if you don't have those skills. I think we've seen some examples in the news of apply chain attacks and things being made easier for um, you know, milicious actors to get their code out there faster without folks knowing. Right, I'm not really sure about that one I had I hadn't heard heard that, but yeah, why wouldn't militious actors be using the same principles to push their attacks out faster. So let's let's examine this term cloud native. And I've had people talk to me that there's cloud native really doesn't exist, it's just a made up term that we're using. But wanted to get your thoughts on when we talk about cloud native, what does that really mean? Cloud native? I don't think it's a made up term. I think it describes something pretty real for for software developers, Um, if you go in into a development of a new application with with cloud as a as the first class uh priority. You're going to leverage platforms, and you're going to go all in on a csp and you're...

...gonna you're going to use all their integration offerings, all their hosting offerings, and you're going to write your code in a way that is native to that csp UM. To me, cloud native is a lot of things. There's a whole uh Kubernetties as cloud native. Yeah, kubernetties is deployments are cloud native if you choose to run kubernetti is on top of the csp UM. Some people refer to cloud native and they mean serverless, like immediately they think serverless development. So cloud native is real and it's a It means to me that where your code is going to run becomes a first class uh uh requirement to the design of the application. And what do you how do you see some of these more niche um I don't know if you call them CSPs, but more applicate very specific application of serverist cloud native providers like you know flight out Io and you know cloud flare not really a niche one anymore, but kind of starting to offer their own uh cloud native services and offerings that are competing now directly with the big ones. From a developer perspective, UM, I think that you're that You're right, it is super niche still right now. But the everybody's trying to provide a pretty similar experience. You see, the major CSPs announced something and then then the next CSP will follow suit, so they are identical services. But everyone wants to have the table stakes to attract the development teams to build on their on their platforms, and the niche players will likely just follow suit as well. So do we end up by...

...standardizing on one CSP or one of these niche providers same place we were before from a monolithic perspective of its inability to move those applications for another environment. Well that's the the hot and heavy religious debate right now. Right Do I do I containerize everything with the hopes that I can move it around to the different CSPs or back home UH and then back out? Do I want this ultimate UH flexibility and where I run my applications or am I going to go all in on a particular CSP right everything in a cloud native CSP native way and gain the efficiencies there. So the clients that you're coming into interact with where are they headed? We see a lot of Kuberneties right now. UM serverless was groundbreaking to say the least, but over time, the developer experience around serverless it just it just wasn't as robust as the development experience around container rised application. So we we think servilis is going to cool off a little bit in favor of Kubernetes and other container orchestration platforms, but not only because of the developer experience. It. That's full circle to the multi cloud ambitions and the multi cloud being so buzzworthy right now. UM a lot of driving folks towards the container experience, and I think that's that's the focus for us right now. So let's talk. You brought up multi cloud and distributed cloud there, what's your insights on this trend. I don't think multi cloud or distributed cloud is going to reach its promise for a while. UM. Even...

...even around the container orchestate orchestration platforms, UM, there's not complete parity across clouds. UM, you still have to deploy separately. I mean there there are companies trying to solve this right single deployments any cloud. There there's software that you can layer over the top of all of your your CSPs and try to get that single pane of glass on a control plane. But I think it's going to take a take a while for that to be really mainstream, especially around security and like identity management. Making an access or authorization authentication change in one CSP and propagating that across to to affect the same deployment and another CSP. There are a lot of complicated things that have to have to be solved for before distributed cloud is really going to be easy. Um. I think it's a great goal though, and I think containerization would be an absolute requirement at this point to even consider making that happen. Does that mean in twenty years we'll have so many abstructions that nobody will have any idea how it actually works? Um, CSP as a public utility? What are the ones and zeroes? Yeah, I mean that's the promise, that's the like the dream of of containerization. Right. It runs on my laptop, It runs in Azure, it runs in aw As, it runs on Google. It runs refrigerator on your refrigerator. It runs on a on a stack at a cell tower on the edge and it and the developer never has to take that into consideration at all. And we can do a whole podcast and on the security ramifications of it running everywhere around that. Okay, I'm gonna give you...

...a couple more friends that you know gardners identified. One is you know, composable applications and enterprise, and another is low code, no code. Wanted to get your kind of insights on those two trends. So composable, man, it can mean, it can mean so much. Um, I think when we talk about composable enterprise, we're talking about UH and enterprise architecture that involves the connecting of both custom and off the shelf uh sas is what we refer to when we say off the shelf. Nowadays, of course, UM, we've eaten together the software that runs your business by leveraging the right service for the right job versus these huge monolithic suites of single vendor solutions. So what that means is when one piece isn't working, you can take it out and replace it with another piece. Right. So, I mean a lot of things in tech are not literal. Uh. I think when we talk about compose herble, it's it really is literally composing your enterprise architecture and the applications required to run your business from infinite lego set of of offerings, and that giving you the flexibility to UH change and upgrade parts of your enterprise independently. Now, when we talk about a composable application from a micro services standpoint, UH, it's about enterprises being able to leverage these services to create new lines of business applications UM by the virtue of reuse of these single purpose,...

...very loosely coupled pieces of functionality. So it can mean a lot of things. Question for you, Fred, because we've been talking about at the application layer, but data just doesn't come along for free. So what are the implications as we start to move to these cloud native that you know, our audience needs to think about from a data perspective? I think so long it's kind of the same thing that that organizations have needed to think about for the last you know, ten twenty years when it comes to their data, which is UM. You know, make sure you're collecting the data that you want and make sure it's accessible and retrievable so that you can either centralize it or put it in a place that UM your various apps can start using it because you know, I think one of the big things we're seeing is as as become more containerized and more distributed and more single purpose. Um. What we're creating is a whole bunch of data silos in the process. And so you'll have very specific marketing apps that do one thing, maybe they only do email campaigns, and then you have another one that's really good at creating personas. Now all these applications need to start sharing data. And if you create this point to point integration, you take away one of those applications and boom, You've just broken the entire spider web chain of data going all over the place. So I think what organizations need to do is start to put plans together as they start to adopt and modernize their applications, how are they going to leverage the data that is uh, these applications are both collecting and consuming, and how can they make that data available UM to the rest of the applications within the organization Suggesting I mean, as you're talking to clients, first of all, is data second class citizen for them? Are they thinking about that holistically? So early adopters of of micro services and the more distributed approach. UH found out very quickly what happened when you move the data into purpose built...

...databases and wall walled off around a service boundary, it becomes very difficult to re aggregate that data and report. And we see the advent of or the re the re emergence of enterprise service bus type connections between micro services. UH so that the right services have copies of the right data. And now that just spawns another problem. Right, So, now you're taken the concept of single responsibility all the way down to data persistence, and now you're making copies of that data. So now this each of these services grab copies of the data they need for performance. You've got an analytics and a reporting uh concern. So where do where do you get the data to aggregate to do the reporting and it and it just goes on and on from there. Right. So, early adopters really uncovered this challenge with a micro service and distributed architecture and we're still solving that problem as a as a group of technologists. So do we still have the term database administrator or has that been incorporated into the developers as a part of just what they're doing, or do they have the knowledge to understand the impact and ramifications of these new services with data. It's another one of those things that like debops and Sadman's it's a little a little bit of both. Right, you get rid of it and put it all on the developers and uh, you know there there were certain dB A activities that have been done over the last decade that you know, data modeling for instance, that's something that belongs more on the business side, co existing with the developers. UM understanding how to UM both secure and size and configure your...

...database and keep it going. Now, a lot of that is shifted to the cloud service providers, but it hasn't completely taken it away, um from the organization's responsibility. So is it the same big job that it was before. It depends on how you're hosting everything. Everything is in the cloud. Um, do you still need a little bit of it? Yes? Do organizations find themselves missing some of those skills? I think definitely us It's it follows the shared responsibility model, uh for the csp s right, UM, what you're referring to, like back ups and archiving and all these things that d B as Uh, that was half of their job and then the other half of their job was to help developers get the schema correct and uh, you know, make a sensible model of of what's going on in the business when you go to these managed platforms, and uh, the at the csp S offer half of your job is now a checkbox that says, please back this up in archive it and pushing the the responsibility for performance and modeling into the team makes the database minded person part of that cross functional development team now instead of sitting with the siss adminds and and the networking folks. So it's an evolution of what what that role can can be. But you're always going to have to tune in performance, tune relational database. I mean, that's somebody always has to do that. Um, but I think we're going to find that those folks are going to be sitting on on the scrum teams versus sitting in the server rooms the virtual server room. All right, I'm gonna kind of wrap this up. How can our listeners know if they're ready? And you know, what are some of the questions they should ask themselves.

So it really doesn't matter if you feel like you're ready or not. The impetus is there. You have to get ready for this and the questions you should be asking yourself. Are am I able to release features to the market fast enough to satisfy users and to keep up with my competitors? Are my developers? Are they able to push out code in a way that is consistent and high quality and supports that ability to push these features out faster and faster. So if you're not ready, get ready, and thankfully we're here to help you with that right and from the application modernization practice at second Watch, we help clients figure out where to start on that journey. Because if you're sitting on hundreds of applications in your portfolio and you don't have good observe ability and you don't have a good idea of what all these things are doing and what their business value is, it can be daunting, even if you feel like you're ready to start. So regardless of whether you're in the cloud already or on prem we can help with that portfolio rationalization and help you get started. Well. I mean, that's gonna bring up another question though, Do organizations and companies have the talent to do this? We're in the talent shortage right now. Do they have the talent to be able to take this on themselves. It varies obviously, but overall, I would say that that's a huge concern. So going back to are you ready? How do you know if you're ready for this? That has to be one of the things that you take into consideration. Do I have the culture and the resources in house to achieve these modernization goals? So a guided application rationalization process is absolutely necessary,...

...regardless of whether you can tackle the implementation and the execution phase or not. And we're can second Watch help clients get ready and build up that talent. So we really pride ourselves on a do it with you approach over a do it for you approach. So when you engage with second Watch and we get through a rationalization process, we get through some deep dive assessments on some good candidates to start your modernization journey. We also can step in and help your teams actually execute this work, and we can neither embed with your team. We can offer a team that execute side by side with your teams. We really are flexible and our intent is to leave the client with the knowledge and the know how to operate, enhance, and run these new applications. All right, last last question, give us a six story of where we've been able to go in and help a client and what did we do, what did we help them achieve. So, we had a client that desperately wanted to migrate off of a licensed database platform onto something open source and managed in the cloud. We helped the client assess the application changes that were would be required, we help them plan for that migration, and we actually executed a successful migration from a very expensive platform to a much more cost effective solution on a managed database CSP all right, well, thank you everyone for joining us here on cloud Crunch. Jesse, I want to say a great appreciation for you coming on to the podcast. This has been cloud Crunch with Michael Elliott joining me today as always has been Fred Bliss, CTO of all Things Data, with special guests today Jesse Saying, Practice Director Application Modernization here at...

...second Watch. Thank you everyone, appreciate your time. Thanks everyone you've been listening to cloud Crunch with Michael Elliott and Fred Bliss. For more information, check out the blog second watch dot com, forward Slash cloud dash blog, or reach out to second Watch on Twitter and LinkedIn.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (43)