On-Demand Webinar: Planning for Success with Public Cloud
Talk to a cloud expert
Read the transcription
Planning for Success with Public Cloud in 2019
[00:00:04] Good morning or good afternoon everyone and thank you for joining us. We are just a few minutes away before we will get started. If you have any questions please feel free to ask them throughout. You can use the questions function in the go to webinar control panel or if you will like you can reach out and send those directly and I’ll share some of that information in just a little bit. And then we will get started shortly so please hang on. Good morning or good afternoon everyone and thank you for joining us today. We really appreciate you taking some time out of your day to spend it with us and hopefully we will be able to make the next forty five minutes or so as efficient and as valuable as possible.
[00:02:28] So today we are going to be looking at a very specific topic but something that has come up quite a bit already this year and really towards the end of 2013 which is planning for success with public cloud as you know we are ServerCentral and the voice on the other end that you are hearing is mine. My name is Chris Rex Steiner and I am the vice president here at ServerCentral. My information is on this slide as well it’s Chris are at ServerCentral dot com. If you have any questions please do not hesitate to reach out and ask you can ask them during the session via the questions capability of the go to webinar control panel or you can email me if you prefer. Either way doesn’t matter whatever you’re most comfortable with. If something comes up afterwards again please don’t hesitate to reach out. That information is therefore a reason I want you to have it and to feel very comfortable and very free to ask anything that you’d like to learn more about. And certainly if I do not have the answer I will marshal the resources inside of ServerCentral Turing group and we will get you that answer as quickly and efficiently as possible. So I wanted to start off today with a very quick quote from a friend of CTG a gentleman by the name of Joe Getz who is the founder of social market analytics. And in talking about the building and the development of SMI Joe said that the most successful companies are the ones that leverage all of the support infrastructure available to them. They build their MVP on the platform. They ultimately want to scale. Now this makes a lot of sense and it’s pretty straightforward. But Joe went on to say something that was very interesting and really sort of caught the attention of the room as he said it. And he said Be sure and take the time to do the infrastructure right the first time this will pay for itself multiple times over as you grow and it will save your ass more times than you can count. Now if you know Joe or familiar with SMG that’s very much in line with sort of their culture and who they are as an organization and who Joe is as an individual. But what I really want to point out is the idea that it is about planning it is about knowing where you’re going and setting yourself up for success. And when we look at the idea of the public cloud and we look specifically at the idea of public cloud platforms in 20 19 that’s a very broad destination. So to start everybody is really familiar with the three core platforms NWS Azure Google Cloud and there’s a host of others. But realistically these are the three that really figure out the shape the tone and the pace of the market and then set that for all other organizations other cloud competitors but also end users of those cloud. And of those cloud platforms excuse me and of those cloud capabilities. Now in most cases people use the term AWS as synonymous with the public cloud. So throughout this conversation I’ll probably flip back and forth between saying public cloud and NWS but we’re really looking at this holistically. So when we think about these three discrete platforms that have very unique objectives and very specific technical capabilities it raises the question of well why do I need to plan right. I’m familiar with them. Everybody knows what AWS is. Everybody knows what Azure is. Everybody knows who Google is and what they’re doing with their cloud platform. But the reality is the plan becomes the most important point of the overall process and really is the catalyst to success so why do you need to plan. Well let’s take a look specifically at NWS and we’re using this as representative of all of the platforms because there’s some very specific metrics that are tracked and they’re pretty enlightening. So if you look at theU.S. Today there over eighteen hundred service and feature introductions that took place in 2018 and the pace of those introductions is accelerating. In fact it’s expected that there’s going to be close to two thousand service and feature introductions in 2019 alone. What makes that really interesting is that this is an expectation. This isn’t someone projecting onto a W as these are their statements about the pace of innovation and the pace of growth of their plot form. Now when you extend this one step further and look at a very specific capability inside of AWS either easy to compute service there over two hundred and fifty thousand skews for that alone so you can start to see the levels of complexity and the opportunity for things to get sideways very quickly. When you look at all of the variance and all the opportunity that exists in these platforms because again we’re only talking about the volume of opportunities and configurations and to be less.
[00:07:25] You can multiply this out across Azure and Google and it becomes substantially bigger next interesting point is that when you look at the raw economics of hyperscale cloud cloud platforms it’s very likely that a static application will be more expensive in that environment. Now this presupposes a lift and shift style deployment. Again there’s a lot of sort of foundational assumptions in this but it’s reality where it can be more expensive and the expectations of an immediate cost savings or an immediate benefit are not going to be realized and that’s across all of those cloud platforms. And additionally something that we see every day that we really feel points to the importance of the plan is that it can cost over four times as much to access the data that you have stored in your public cloud platform than it does to store it. So that’s a really interesting point. So accessing your data is going to cost more than it does to store it. And if you have high access rates that’s going to become tenuous very quickly. And the reason we point this out is that it’s typically about once a week maybe twice a week. Now we have an inquiry from a company that has a multi tens of thousands of dollars a month bill from a cloud platform that is driven purely by ingress and egress of data and it’s something that wasn’t planned for wasn’t expected isn’t necessarily understood but is a very real problem because it’s real money. So it’s something to also think about in all of this is that the costs of cloud platforms are very very different and the impact they’ll have on your business is very different both at a financial level and then at the planning level.
[00:09:12] So some interesting data points to sort of set the stage for why the plan becomes so important and knowing where you want to go and what you want to accomplish is really the critical success factor. So if we look historically which sort of it’s important to know where you are and where you’ve been to know where you’re going. So if we look slightly backwards we say well what has the plan been for cloud success. It’s really predicated upon something that everybody should be familiar with a remotely familiar with the idea of the four hours on that’s re host refactor re architect or rewrite.
[00:09:46] And what’s interesting about this is that these individual capabilities these individual objectives are purely technically focused and while that’s very valuable because the cloud at its core is a technical decision it’s a technical asset. What happens is something very serious occurs and that occurrence is the fact that the business value the business objective is removed from that plan. The plan is achieving one of those four hours lift and shift to be a re host all the way through rewriting something from the ground up. But the challenge is that those never get associated with the business they never get associated with the larger objectives that are going to drive the company forward. Typically they become resolution to a challenge or quite honestly the solution to a problem that somebody doesn’t know how to address in another form. So when we take a step back and we say now what is the business value. Why are we looking at the cloud not just the technical opportunities to pursue but the business value. We did a lot of research in this area to try and find out a way to sort of structure this. Intelligently but also simply and what we’ve found is that there are really five core outcomes or five core value statements that an organization will pursue relative to their cloud plan or their cloud strategy. And those are growthI.T. optimizationI.T. modernization digital transformation and business continuity. Now inside of each of these are a host of opportunities or challenges or problems that really roll up into these larger concepts.
[00:11:31] So what we did is we took the hundreds and hundreds of different sort of problem and opportunity statements that exist in that we learn about from our customers and prospects and partners in all of the conversations we have. And we rolled them up to identify what these larger trends or larger objectives are to make this a little more digestible if you’re interested in learning more about the specific challenges or objectives inside of any of these larger values. Please let me know I’ll be happy to share that information with you only can dive in at length as to what is growth. How are people approaching that. What is growth look like in terms of challenges and opportunities that are both tactical but also very strategic and have an immediate impact on the infrastructure theI.T. strategies the cloud strategy necessary to achieve it so by looking at what each of these individual outcomes represents it will provide an immediate connection between what the technology is and what’s going to be ultimately delivered to the business.
[00:12:36] And the reason why we focus on this is because at some point in time as the cloud becomes more and more mature inside of an organization a very specific question comes up. And that question is what is our cloud our ally. And for many organizations the aura lie of a cloud project was never defined because it didn’t need one or didn’t have one. And the. Village with this is that it becomes one of defending investment and defending decisions very rapidly as budget and as resources are being allocated. And while there’s a financial component of this it’s also important to remember that there is the business outcome perspective of this and that is what is what is it that’s trying to be achieved. What is that larger outcome that is trying to be realized by the organization so that that benefit can ultimately be connected to that investment. Now that seems very trivial and it sounds really trivial when I say it but it’s super important because it doesn’t happen and all of a sudden things are sideways because there is no connection of the technology to the business. One has happened without the insight or really the connection to the other. Now the connections exist but nobody’s bothered to shepherd them to put them together and guide them through the organization so everyone understands what those impacts are. Now I’m going to provide a little bit of an example in terms of that our ally side to give you a sense of what happens and what it really looks like. As this evolves so inside of most organizations once a cloud decision has been made it doesn’t really matter what that decision is it can be public it can be private hybrid doesn’t matter somebody says we’re going to the cloud this is what’s going to happen. There is an expectation that immediately the benefit will be realized that the transition will take place overnight in what happens in reality is that it is typically a three to five year process. Now we model out all of the transitions for our customers and for a host of internal projects to look at what really happens once these decisions have been made. So in this example we use a five year window because it’s probably the most common and some people will see this in three years and you just condense everything but realistically five years is what it looks like there’s lots of reasons for that but what happens over that five year window is that any sort of data center or on prem infrastructure and application investment slowly declines and that decline is based upon the migration of the application or the rewrite or a refactor or re architect depending upon what the objectives are again. But what’s interesting to note is that at the completion of the cloud project that idea of on prem infrastructure and applications and again on prem could be on prem or in a private data center whatever not cloudy things will typically end up being about a quarter of the overallI.T. investment or theI.T. budget conversely the cloud typically gets to be roughly about 70 percent maybe a little bit more but roughly 70 and then as a general rule we typically see about 5 percent of that overallI.T. investment being put towardsB.C. assets. Now what’s really interesting about this and why we really try and point this out it’s a little bit difficult to sort of wrap your head around all of this but it is really important is the idea that you’ll notice this is in percentages on the left hand side and you’ll notice that at the top it stays at 100 percent. And the reason we point this out is because in most instances thatI.T. investment. Doesn’t really decline it stays consistent. TheI.T. investment doesn’t drop to 90 percent of where it was or 80 percent of where it was. It really stays the same. It might go up a little bit or might go down a little bit maybe a few percentage points one way or the other. But in general it stays the same. So there’s an immediate expectation that this cloud decision has been made in theI.T. investment is going to decline. That doesn’t happen now. There are instances where it does. But on average it doesn’t. And if it does it’s very nominal. So all of a sudden everybody’s a little bit off kilter because that. Activation hasn’t been met. But what happens is there’s really a host of benefits that occur underneath that investment. And one of the biggest ones is that the actual transition or the most immediate are a lie available is really driven in terms of staff availability. Now most people are familiar with the rule of and sort of the Google rule or the 20 percent rule where people try to set aside one day a week 20 percent of their time to focus on innovation to focus on development on net new projects. One of the things that we’ve seen in researching all of this is that while that budget remains very consistent as the cloud transition occurs what happens is a really significant shift in staff availability for innovation and a lot of define that for a second because many people see that and they think oh that means we need less staff. And the reality is no not necessarily what happens is today people are spending about 80 percent of their time keeping the lights on keeping the systems running. And over the course of this cloud project it actually inverts so that instead of spending 80 percent of your time keeping the lights on you’re spending about 20 15 to 20 percent of your time keeping the lights on and the other 80 percent. Eighty five percent can be applied to solving other business problems to really adding value into the business not worrying about the sort of day to day technical issues that come up because a lot of those gets solved as part of that cloud transition as part of the cloud platform. Now if anybody has read the Phoenix project that’s a really prime example of this in terms of what really is or isn’t work. And that book is a very tangible example of this transition where all of a sudden those efforts focus in a very different way and deliver very different value to the organization. So if somebody says well what does the R Y on the investment we’re paying the same amount of money. Well yeah you might be it’s very likely you are. It’s shifted from cap ex to OP X or it shifted from buying hardware to investing in other organizations or other platforms. But the real transition that never gets accounted for is staff availability staff execution and ultimately the employee satisfaction and retention. And that has a very material impact on the overall success of business. But it’s never calculated into the LIE OF A CLOUD project. Now there’s a lot behind that we can do probably two hours on that concept. So I want to set that aside for now but something we can come back to at a future point in time and if you have questions please ask. But it’s really important because now all of a sudden a key element of the R lie of a cloud project is present. It’s calculating it that becomes the next challenge. Now once that are lie can be addressed there’s a way to answer it. The next question that typically will come up is well what are our KPI eyes. Now that we’re in the cloud and those Keep your eyes become very different because the focus goes from infrastructure to applications. And it really centers in three key areas and there are myriad KPI is like almost almost countless but it’s pretty close. They really center in three key areas and the first is in application development and launch. The second is an adoption. And the third is in satisfaction. And the reason why I point these out is that when you look at what the cloud is just as you have a whole new way of looking at our lot you have a whole new way of looking at what the KPI is are. So things like meantime to recovery become really critical because they are a function of employee satisfaction or customer satisfaction with those applications were in the past. Empty TR has simply been in metric that theI.T. team measures to see how long is it going to take. If something goes wrong for us to recover it’s not really tied to what is the employee or customer satisfaction. What is the adoption of that application and what is the impact of time to market for those capabilities. So the idea of the KPI is also has to change in order to represent the new state of the business again a couple of them here to sort of help point in the right direction but if there is any questions we can dive into substantially more detail about that if necessary. So the underlying part of all this is Will what is success look like. How do you truly put yourself on a path to realize your plan and to realize the success utilizing public clouds in 2019. And we looked at cloud success and we looked at it as a continuum because as you saw in the our ally section it isn’t a flash cut. There’s no sort of magic button you push you’re in the cloud Everything’s operational and every benefit has been realized. It’s actually a function of four very different areas. And the first one is strategy. That’s what are you going to do why you’re going to do it and those outcomes we talked about the second our data centers. And this is really important because they’re going to be applications. There’s going to be infrastructure elements that aren’t appropriate for the cloud. What are you going to do with them. Where are they going to go. How do those legacy systems. Because in most cases it’s legacy systems get managed. Then there’s the cloud and then there’s the idea of the cloud native software development. How are you going to refactor or rewrite applications to take advantage of these platform to really realize the benefits that the technology can provide in order to achieve those business outcomes. And what we’ve seen is that a lot of organizations recognize the last three. They recognize that their legacy systems they recognize there’s clearly stuff and they recognize they’re going to have to do some software development work in order to make it work or really achieve the objectives they want from those platforms. But what happens is they don’t connect and the reason why we highlight this is because the skills that are necessary to connect this are very very different. When you’re looking at strategy and the transition from strategy into execution and then really on the backside of that into development you’re talking about professional services engagements working with organizations that have consulting skills fingers on keyboards and expertise that can deliver to support those objectives. When you’re talking about the middle process of this you’re really talking about the establishment of a series of managed services that will support what you need in those environments. Now a little bit of this is splitting hairs between what is a managed service or what is a professional service. But it’s important because in a professional service model you’re going to get an asset back that you can do something with. Now that might be the assessment. It might be the strategy document it might be the overall business plan. It could be the application whether you’re looking at strategy or you’re looking at development but in the middle a that managed services side. What it really focuses on is the ongoing and day to day support of your business to achieve your objectives and making sure that those actions align with the overall business outcomes. So it’s a combination of those two capabilities across these four core areas that really set up the best foundation for success with the public cloud. Now there are lots of other ways to do this you can just dive in lots of organizations do it but in our experience that typically leads to a host of challenges. Most of them around financial performance meaning it’s going to cost more than it was expected or the capabilities aren’t going to exist that were anticipated. Things like auto scale things like the accessibility of development tools they’re there but they have to be intelligently brought into the process to be intelligently brought into the environment the applications and the infrastructure in order for them to truly be leveraged. Now that sort of cloud one to one but it’s a really important point. Is it something that gets overlooked in sort of the rapid approach to trying to get to the cloud in a very very timely manner so when we sit down and talk with organizations about what their strategy is what is their objective. What do they really want to achieve. We get littered with questions and what we do is we capture each of these questions and we do so because they’re not unique. Lots of organizations struggle with them or are trying to find the answer to them. So what we do is we capture each of these and then work to find the best possible answers for them. Now what we did for this particular sex session excuse me is take a look at the questions that are really around the success the higher levels for allergy and planning into what the cloud will deliver in 2019. So there’s a host of more technical questions again I’m happy to dive into those afterwards but sort of keeping that top level within the plan within the success strategy. Where do you go and how do you get there. The first question that typically comes up is how do we move legacy applications to the cloud. And this is a really interesting question because it’s asked in two ways and it will come in as we have legacy apps. How do we move them or it will say can I lift and shift. Can we lift and shift our existing applications and move them to the cloud the reality of this is you certainly can. And one of the challenges in it is that a lot of the underlying and inherent benefits of the cloud aren’t going to be applicable to your application. You can move anything at the end of the day they’re victims or their containers depending upon the technologies you use and you can pick them up and move them from location to location B. The challenge is that a lot of the capabilities of those platforms of AWS of Azure and Google aren’t going to be supported when an application is just lifted and shifted onto that platform. So it can be done but the expectations have to be set now for many organizations. The transition from CapEx to OpEx is reason enough to make this shift. It’s reason enough to quote unquote lift and shift existing applications for other organizations. That’s not that’s just a first step. So it’s very common to see this occur and then see further processes take place. Further projects take place things along refactoring or rewriting and really getting the applications integrated to the cloud platforms occur after that lift and shift that’s typically the result of a need to exit the CapEx side of the equation and move over to OpEx so it does happen. It’s something to be aware of that it can be a first step to a curve for an organization another question that comes up sort of after we’ve answered that and these are a little bit sequential is how quickly can we move to the cloud. And the answer to this is unfortunately it depends. But in reality as quickly as you can move so applications if they’re very clear if they’re clearly defined if they’re known if they’re well documented if the interconnection with infrastructure elements and other applications are understood it can be done very very quickly. If the business users of that application are aware of downtime or can be easily connected to the application in a new location it can happen very very quickly if their scheduled maintenance windows. It can happen very quickly. The question is knowing what you have around each application to then know how quickly it can move and what those outcomes are. It’s not uncommon and we had an issue come up last week with this where we had an organization approach us with a much larger challenge of exiting an environment very quickly because of some issues with that platform. And they said how quickly can we move this. We got to we got to move it now. And the answer was OK. And within about a half a day everything was moved. Now some of that was physical and some of that was virtual. But you can get a sense for how quickly things really can happen when they need to. The question is just what is the best way to pursue that and what is right in line with the larger business outcome. Does it put you on the right path. Is it the destination or is it just one step in that direction the next question we hear is which apps should I put in public clouds. And this is a very loaded question because in reality you can put anything there you want but there are very specific characteristics they’re very I want to say unique but they’re very sort of inherent objectives that can be best achieved on those platforms. And when we look at how we are approached with different applications in different environments we’ve really identified about six super clear and concise environments where it makes a tremendous amount of sense for the public cloud to be the destination and the reason for this is that the development tools are the critical success factor. The development tools the development environment of that cloud platform is what will enable that application to achieve the business goals. So for very seasonal applications things that have very spiky compute requirements very very prime prime environment to go to a public cloud. We see a lot of organizations who are looking for security and identity solutions not quite as much compliance but more security and identity solutions looking very closely at the public clouds. And the reason they’re doing that is because the existing capabilities on a number of US Azure and Google and predominantly NWS it’s much more advanced there. But it exists obviously on Azure because of active directory and within Google. But you have identity management and security capabilities that can be leveraged without having to write any code zero. You can literally deploy the tap into them use them immediately and bring your applications to market bring capabilities to market faster. So when net new changes are needed in those areas we’re seeing a lot of applicability and a lot of benefit in those public cloud platforms for the organizations that are working with a are in VR. We’re seeing a lot of value there too. The reason being is that those tools exist and they’re very difficult and very timely or very expensive in terms of time rather to create. So why do you want to create those quote unquote creative tools when you can leverage them. The same goes for IO T in machine learning and for media services. Many services a little bit different but for IO T and machine learning is sort of theA.I. side of the world if you will. Those tools exist. You can write them or you can tap into them and tapping into them becomes a really critical opportunity to do something quickly and to test with much less investment that is needed to build it from the ground up. For instance if you’re looking at different email environments orA.I. environments there are hundreds and hundreds and hundreds of configurations that exist on a US alone that you can tap into and that doesn’t say anything of what exists in Azure Google because it triples that that you can try and see do they work. Do you get the result. Are you achieving what you want without having to invest anything in building them. They’re there for you to build from. So we see a lot happening there. Application Integration is another one and this is a little bit different in terms of what we’re seeing move to the public cloud platforms but it’s being driven by the idea or the requirement that applications need to talk to lots of other applications. Think of API or micro service type environments right where you’re moving lots of information and lots of functions across different environments. One of the things we’re seeing is very very applicable for the public cloud platforms are environments that have a lot of interconnectivity with third party apps and data. And the reason being is that you have a whole host of permissions and a whole host of requirements necessary in order for those integrations to occur and a very simple open common denominator are the public cloud platforms. It’s something that everybody can speak to easily and from a connectivity perspective it’s something that everybody can connect to also easily and deliver that capability without having to worry about proprietary connections or having oneI.T. organization talk to anotherI.T. organization that’s easier to use that intermediary of that cloud platform to help make that a reality. The final one is really a media services. And the reason we’re seeing a lot of this is because writing and building streaming environments for media and as well as indexing and storage capabilities is really expensive and it’s quite difficult but those services exist and can be tapped into. And with the desire for companies to do a lot around the media a lot around streaming it makes quite a bit of sense to leverage those capabilities that exist and focus on the value rather than the underlying platform. One of the things we’ve heard about this actually just this week that sort of drove this home was the fact that when you look at the media services that exist on the public cloud platforms they innovate at a pace that exceeds what any one or any like really multiple organizations are going to be able to achieve. So you can do one of two things. You can try and build feature functionality as fast as the market is or you can leverage what is being built. And it was pretty insightful to hear from a media company say it’s it’s not even worth the time or money to build it. We can leverage what’s there and achieve what we want which is focused on focusing on the content focusing on the end user engagement rather than what the underlying media capability is after we talk about this the question comes up about the developer tools and do they really matter.
[00:36:04] And if so how much do they matter. The one thing I would say is that the development tools matter a lot and they don’t matter technically as much as they matter. From a personnel perspective the reason why I say that is that it’s very difficult to attract and retain technical talent. If you’re working with antiquated tools I’m sure everybody knows an organization knows someone perhaps personally that has a whole host of legacy applications and one of the biggest challenges they have is finding individuals who know that language or who know that platform and can support it. Everybody wants to work with the latest and greatest tools. Everybody wants to work with the new hotness rather than any old busted platforms or old bustin technology that’s still there because nobody turned it off.
[00:36:51] So those tools do really matter but they matter more in the attraction and retention of that talent of the people who can help drive those net new opportunities forward rather than reaching backwards. That’s a little bit of a tenuous balance inside of any organization because you do have to have a lot of those other skills to keep things operational. But looking forward and in terms of bringing in net new talent into the organization those tools become very very significant in terms of getting people to join the team and ultimately want to stay there and contribute to the company’s success. A tangent question that comes up a little bit more on the technical side is about serverless and there’s a lot of interest in this because it really does represent the idea that you’re going to pay only for what you use. We’re only when that service runs that you’re going to actually incur a cost. And there’s lots of interest in this and the sort of answer to the question of should I make existing IaaS serverless is probably not the larger question is what’s the objective and what are you trying to achieve. What do you want. Who are you connected to what information what services need to be available and approaching it on a little bit more tactical level to understand what needs to occur and that idea identifying the best way to deliver it. So in many instances the objective or really the benefit isn’t to take an existing application and figure out how to make it serverless. Rather it’s to look at the individual services or the business logic that exists in the application and determine how that can be applied in a broader way. The reason why I highlight this is in many times many conversations this convert this question comes up and what it really gets to is a very different underlying issue and that issue is if I move serverless I can achieve something else. I can do something different. I can deliver a platform instead of delivering an application. I can change my market opportunity. And when you realize that the underlying objective is to do something different is to go from being a product company to being a platform company or to being a SaaS company now all of a sudden the idea of serverless the idea of micro services the idea of integrations takes on a very different meaning and it doesn’t become a function of saying how do I make it or should I make it serverless it becomes a question of what is the right way to deliver those capabilities for that market. And we see this happening more and more with the idea of serverless come in coming in excuse me part of it’s driven because you have lots of people who want to work with it because it is really really cool. But it’s also being driven from those larger business objectives that require a lot deeper level of strategic work to determine the best way to have it deployed in the best way to achieve the benefit for your business and for your end users. So the short answer is probably not the long answer is you’re probably gonna have a lot of serverless and a lot of micro services going forward as applications simply change and evolve but it isn’t going to be an existing environment that’s going to make that transition. It’s going to be more net new capabilities one question that we always get asked and I sort of put this last because it’s a very big issue and it is is auto scale enough to justify a cloud project. And whenever we’re asked this question it really is centered around the idea of being able to add and remove resources as needed to optimize what an organization wants to do. So whatever we see or hear this question it immediately points back to those outcomes I mentioned earlier and it is an immediate flag that says OK there is an optimization requirement inside of the business. The question is what is it. Is it to remove legacy infrastructure. Is it to end of life applications that really don’t want or need to be supported anymore or have to be supported battle to be supported. So understanding the nature of the question becomes very important to getting to the right answer. So is auto scale enough to justify a cloud project. Probably if you have a high degree of variance in the use of your application high seasonality. Yeah it can be more than enough to justify it. Is it enough to justify a project when you don’t have a high degree of seasonality and you have a very steady state application. No it won’t. Because those benefits really won’t be there either technically or financially. The other part underneath this is to determine what does auto scale mean for your organization. Is it the addition of resources to support seasonality spikes or is it the ability to quickly bring online and then take offline development environments and auto scale is very similar to where the term cloud was about five years ago where you’d walk into a meeting or you’d sit down with someone to discuss what they were looking to do and they would start talking about the cloud and you’d sort of have to stop and say OK when you say cloud what do you mean. Well now there’s a lot of understanding there’s a lot of commonality in the use of that term. Five years ago there was a you’d ask five people and get like 10 different answers because everybody has slightly different objective or slightly different definition auto scale is in that mode right now where it means for some people supporting seasonality supporting spiky behavior in the application. For others it is the introduction and quick removal of resources to support different environments different requirements things like Devin testing things like a net new business unit can be spot up while we get them working. Yes OK. Then they were going to be integrated back into other systems. So it really is understanding what auto scale means and then understanding what those underlying objectives are. It can absolutely be enough to justify the product but it can also be an objective that is best met in a different way. And again I don’t mean to belabor this but it’s becomes very important it’s extremely common to have an organization of protests and say we moved this application to the cloud because we need to scale for the summer or for the holidays and they move to the cloud. They spin up tons and tons and tons of resources. And then they don’t turn them off. And they have a massive bill as a result of it because there there’s no governance. There’s no management there’s no monitoring of that environment. This happens every single week. We get this question and the expectation is that auto scale is magic and it just occurs. And the reality is very different. It doesn’t. So you do have to understand exactly what is meant and what is necessary in order to know can that justify the project.
[00:44:28] That’s a really long answer. Sorry about that.
[00:44:33] There are always additional questions that we get asked but what I’d like to do rather than just burning through all of them is pose this out to everyone participating today. Are there any particular questions that you have that you would like to see an answer for. Or discuss again we can do that now. We can take that off line if you prefer. Please feel free to reach out again. Chris are at ServerCentral dot com and I will be happy to answer those directly Well the first one that just came in. Thank you. Is is refactoring really enough to take advantage of the AWS native development tools. That’s a that’s a really really good question in many instances a refactor is much more than a refactor and by understanding where the edges of that project are you can truly take advantage of the cloud. Native development tools as part of a refactoring effort. Now it’s most common to see those tools brought in in a rewrite or in some cases a re architecture but mostly in a rewrite in the reason being is that the tools are used at a slightly different level in a refactor it typically will be the use of scripts that will connect to those capabilities to invoke what you want to occur. So think about scripted auto scale right. It’s not a native piece it’s a script that runs that has different parameters that exist sort of outside of the environment rather than native to the environment. So it is enough to take advantage of them. But is it enough to truly integrate all of those capabilities. Probably not. That’s going to occur at the rewrite level now. There’s lots and lots and lots of ways to phase this in to achieve incremental benefits not out of the scope of any project and certainly not out of the realm of reality. But that’s very specific to an individual or to an application basis. On that lines of what is the difference in the development tools between eight of us as you’re in Google Cloud The that’s a that’s a really good question and there are some people inside of ServerCentral Through interpreter who are much much much more capable of answering that than I am. But I’ll give you a high level answer on it. The difference really comes down to maturity. So Microsoft’s development tools are all based upon the concept of Visual Studio and Visual Studio is one of the most advanced development platforms on the planet. Anything and everything you’d ever want to do with application development is pretty much there. However it’s very Azure specific as you would expect a W us as development tools are very AWP specific and Google for a Google specific Ada Glass has invested aggressively in their development tools to make them as efficient and effective as possible but they’re done in a different way than visual studio is created.
[00:47:55] So the idea of services really become very prevalent in the AWS development environment and a little bit less so in the azure environment because of the nature of Visual Studio and the nature of Amazon offering capabilities the services that’s changing and that’s sort of equalizing more and more each release.
[00:48:15] But that’s a little bit of a difference in it today.
[00:48:19] I would say from a maturity perspective you have cloud native development tools on NWS are phenomenal application development tools on Azure phenomenal and Google very Google specific. Nothing wrong with that but it’s probably not as advanced or as mature as the other platforms are at this point in time. Alas what we have here is why are there only five business outcomes. And what’s the difference between optimization modernisation and transformation. So let’s break this up into two parts. First of all on the business outcomes why are there only five.
[00:49:00] There are potentially an unlimited number of outcomes. What we did in that effort is we simply rolled up all of the objectives opportunities and challenges that people come up with and tried to find the commonality. And for us at the end of the day they really fell into those sort of five buckets. And growth is very self-explanatory. The company that the business wants to grow it wants to enter new markets introduce new products do that faster update existing capabilities faster. Really that traditional sense of growth optimization really refers to improving what you’re doing. Understanding that what you have is what you need. You’re not wasting any resources. It really is focused on what exists today and getting the most from it. Modernization is different in the sense that it really reflects the introduction of net new capabilities. It isn’t tweaking or evolving or improving something you’re already doing it’s introducing net new things net new modern platforms modern applications that will support those business objectives. So where optimization really is working with what you have. Modernization is really the evolution of that sort of end of life thing or replacing or upgrading into net new capabilities and transformation is really sort of a strategic extension of modernization for lack of a better description. The difference with transformation is that it really is driven from the way the business operates not from a technical perspective.
[00:50:43] So if you think about optimization and modernization those are both prefaced withI.T. or y because that’s the goal. It’sI.T. optimization it’sI.T. modernization but the transformation or digital transformation is holistic to the business. It isn’t just theI.T. components it’s business processes it’s customer engagement it’s sales channels it’s everything it really is thinking acting working and really being in a different state as a business than you are today.
[00:51:16] So the difference there. In some instances gets a little bit grey but really does center around those core capabilities working with what you have introducing new capabilities and a transformation throwing the baby with the bathwater out if you will and really having a net new approach to how the business operates rather than looking at it from a technical side up don’t have any other questions on there now. But I am more than happy to hang around for a little bit if anybody does have anything they would like to ask but on behalf of everyone at CTG I would really like to thank you for taking the time to join us today. Hope you have a wonderful afternoon and will be joining us again in the future for our next webinar. Thank you very much.