Which Application Modernization Pattern Is Right For You?

good morning good afternoon good evening thanks for joining us today depending on your time zone really excited to have you out here today so we are going to be talking about F modernization and walk you through the different kinds of patterns and you know hopefully help answer questions like which one's right for you so to do that we are joined today so myself principal Bogle I'm part of the apogee / Google cloud product 19 and a drive a few different port areas for the company vertically one in particular that's relevant is I manage all of our civil cloud pivot rows without boundary integrations that we have from an a/v perspective and our partnering time today is Sean Sean over to you yeah hi thanks Brett well my name is Sean Anderson and I am a application transformation practice lead at pivotal and what that means is I help customers transform their applications from legacy monolith applications to modern applications that run on pillow cloud foundry and take advantage of all the benefits they're in so Sean this is a this is a pretty important area it's very much top of mind for many customers that I talk to on a frequent basis so let me just kind of walk through for the benefit of the participants the agenda here so we're going to talk about why modernize let's see what we can do with a monolith I know you have some interesting insights of there Sean then we'll get into why API management and you know why that as a strategy has been working out for many of your customers and go touch briefly on some of the integrations that we already have in place for the benefit of our participants today talk about a customer benefit and you know we'll be taking questions as we go along but we may have some more time towards the end for some Q&A or the webinar channels well so at this point I'm I'm going to turn it over to you Sean take it away okay so we have a short amount of time so I'll be skipping fairly quickly through some of these questions like what is pivotal Cloud Foundry that probably will take more time to answer than we have on this call but at least at a high level we'll be able to answer that in in simple terms that Cloud Foundry is a platform for developing running cloud applications that's that's pretty simple but really what that means is guided by Cloud Foundry principles we aim to help enable developer productivity through operational efficiency and also enhance security posture and I'll talk a little bit more later and why that's important but that's the basics of cloud foundry is to try to get your developers and your applications to bring value to the business as quickly as possible so I think most people on the call are experienced with the the traditional application lifecycle it's often very lengthy and complex through traditional development up you usually have at least eight manual steps and and developers are often out of the workflow so you may have one team that scales and sizes servers that are requested for a new project for example and then you have to wait for the hardware creation and sometimes this can take you know weeks or months in between then you have to set up your operating system make sure that you've got your patches correct and in some times another week or two to get that going and then finally installing the software setting up your monitoring doing the deployment all of that process can take a lot of time and add a lot of complexities so during that whole lifecycle you've got up to seven ten major steps manual activities in in some cases you'll have creative developers that will automate you know pieces and parts of that but in general you don't really get a cohesive way of building software where you can just basically push a button and have things automated the other part of this that of course most people are familiar with is when does all this have and especially the end points where you're deploying to production typically is 2 a.m. on a Saturday as opposed to during the middle of the day when everybody's working and out of constructive laziness that's one of my core tenants is to try to keep people from doing deployments and building software that way so how how does the cloud native platform help enable that well on the left you can see the traditional IT model is where you manage all of this you manage the networking servers if you're using virtualization you have to manage that often these are separate teams with you know separate queues of work to to do all of this and and so that led to the advent of infrastructure as a service where at least some of that was managed by the infrastructure so the virtualization servers the networking all your storage is a little bit more consistent but as an application team you still have to manage the vos in middleware that you have the runtime and certainly your your applications so what that led to is typically again you have your teams organized by by horizontal slice there so you may have a database team that is in charge of everything database and that becomes a bottleneck so for cloud native everything other than applications and data is now handled by the cloud platform and for reasons that hopefully are obvious that's beneficial to us as application developers because we don't really care what operating system or more importantly if that operating system is patched to the current version we don't care about scaling your your virtualized servers and of course networking is already in place for us so what this allows us to do is build applications that are focused on being applications and spend our time more efficiently getting value out of the business as opposed to you know doing menial tasks and having blockers why modernize hopefully that is a question that most people already understand but really one of the biggest reasons is over time especially for large corporations you tend to build monolith monoliths don't have to be bad a monolith can be good if it's got the you know compartmentalised componentized kind of units of work inside of it but typically monoliths tend to be overlapping and even repeating work and and deploy to one large platform like you know WebLogic of web methods or websphere or something where you have a big giant unit of work and and it causes issues of course with you know looking for your fast release release cycle it's usually you deploy something in the Big Bang a large deployment that takes six months to plan and you're doing impact analysis for weeks to make sure that what you build didn't break something and it's way too large for any one person to fully comprehend so you have Reliance's across teams to do to do the work another piece of monolithic applications that is is bad and could be costly from a operational expenditure point of view is your infrastructure utilization is often very inefficient and that that means you know if you have an application that during Super Bowl Sunday at halftime hits a certain level of utilization usually when you're planning that that application and the software and the hardware around that you plan for the peak usage and that's what gets pushed out so in reality your application is running a 5% utilization for 99% of the time that other 95% of horsepower that you're wasting is costing money and also you have a reliance on expensive software I'm sure everybody's familiar with software licensing models and companies that are they get you and then they keep you right and and you don't have the ability to change out of new you going to change your database for example or swap out something more modern again why are we you notice I mentioned something about the operational expenditures but also part of why we want to modernize is to increase our dependency on capital expenditures so using open source but also by rapidly being able to deploy applications you're able to respond to business issues and capabilities much faster than the competition for example so if there's a new feature that your customers demand that your competition can't deploy for six months and you can get it out next week that actually will give you an increase in market share which more than pays for your development in a matter of weeks rather than just saving money nickel and diming on the operation side it also will increase your productivity from the developer standpoint and keep your operations controls in place so that's important in a lot of ways but not the least of which is through your release cycle today if you're using a monolithic application and a traditional life cycle you have gates that you go to for deployment you may have a security gate where somebody has to review and that takes a week and then you have a performance gate and integration testing gate and those gates are designed to slow you down by modernizing our applications you can have your infrastructure set up so your security model is always the same so you only need to get it approved once after that you shouldn't have to go through that gate and so on with your infrastructure and testing and I'll talk more about testing in just a minute here so in pivotal we have two terms one REE platforming one modernization and it's important to level set on what those mean to the audience that you're talking to in in my case I think of Reap lat forming as basically doing the bare minimum you can for an application to get it to run on Cloud Foundry that may mean that you're you're making changes to the logging so it uses cloud foundries event stream for logging but it also may mean that you're you're making some changes to configuration things like that but you're trying to do just the bare minimum to get an existing application up and running on Cloud Foundry to take advantage of you know the platform and also the automated CIPD process for deployment but that's where that stops the next step is modernization which is where we're really looking at organizing the functionality or organizing your applications by functionality and business context so this is more of the domain driven design to make it more compliant to Touro factor services so you really taking advantage of your full infrastructure now the modernization can be challenging because typically a modernized application is taking bits and pieces across your your monolith so you may be taking code or reusing functionality from several different places and you have to continue that you know keep your application up and running your monolith needs to be running as you're building these but there's techniques that we have and part of the techniques that that we look at is we're going through this this application journey is just walking through from left to right where your goal may be in many cases they have a full cloud native application running on pivotal Cloud Foundry which is the right-hand side but you may take that through steps we want to iterate and do small chunks and small releases first step is getting your application to run on pivotal Cloud Foundry so that runs it's not necessarily 12 5 2 compliant it may have you know one or two the 12 factors but you now have a capability to start modernizing your application to where you get it to run well on pivotal Cloud Foundry so that your applications have been refactored using the 12 factor principles and you've introduced test-driven development your pipelines and so forth and then if you choose to go all the way to the cloud native on the right now you you organize your teams around the the way you develop your software as well as taking advantage of all the principles that you have for the previous step so all of this is a life cycle where it's not a big thing we suggest you start small and iterate and there's two approaches when we talk about strangling the monolith the first one that often people look at is what I call the bottom-up approach and that's on the right side of your slide that's decomposition looking at pain points of your current monolith and that's a natural place for developers to start looking because they want to reverse-engineer the code let's look what's happening today with the software let's even parse your text if it's a COBOL application for example let's let's just run it through a text parser and see what's there and get analytics but that's starting with what's existing the the approach I prefer to start with on the left is the top-down approach and that's where you're really looking at your applications from a business perspective it's more of I don't really care how it works today I I want to care about what it's doing and through this perspective you get a little bit more ubiquitous language out of it so both the business in the non-technical people then understand what we're talking about on the technical side from you know a domain standpoint and also a functionality standpoint so it's more important to know what the application is supposed to do for a business then how it's been doing it so far hey you got a couple of quick points I think these are Vida or you know topics which you know I run into a lot may be helpful to kind of maybe relook at some other things here so just use in your experience when you're talking to customers do they understand like you know the differences between button you you you articulated in a very great way about the difference between re-platforming and modernization right so I have two two questions for you one is do you believe in your experience that customers actually understand the difference in these two and when it comes to monoliths right cuz that's the big piece that we're dealing with especially when it comes to modernization do they have a pretty good grip on you know the kind of problems monolith creates and how important it is to be able to be composer yeah these are good questions and answering it backwards from the monolith standpoint I think most customers at least start out under meaning that there's there's some pain but until they have a perspective of there's better ways to do this to really to alleviate the pain they often don't realize how much pain they have you know especially because you know I've been working on this application for the past seven years and this is just the way we do things but there's always frustration so I think understanding the pain of a monolith is there but knowing how to break out of that is is not always there as far as we platforming modernization I think at first most people most customers think of them as one in the same hey if I get if I get things running on the cloud then I've modernized it and that's why the the journey that we we typically go through is important so you can realize there's a lot of benefits that you'll get by modernizing that you don't necessarily see just by replay firing so it's it's kind of a you know the first step is reap lat forming you get a lot of benefits and then modernizing your business becomes optimized and current thank you that makes sense yeah absolutely good so one of the common principles that most people have heard of at this point is domain driven design part of modernizing is we think in terms of domains for your business which you know and I like quoting Wikipedia because it's not always wrong but in this particular case that our domain is a sphere of knowledge or particular activity I think of it in terms of an inventory system that's that's a domain but what's difficult is how do you get those domains driven out of your your your company right everybody has a different company and and we we have things that happen in our company but what's happening so we'll use a technique called event storming where we look at the domain events and this is what's happening from the business perspective it's a it's an exercise that is not just technical where we'll just walk through the process of hey if I want to do sign up for service at t-mobile you know what are the events that are user would go through they start at a webpage and they push a button and what happens and so we talk through the entire lifecycle of that process and in the end what you generate is something that looks like this and I know you can't see everything but this is a a full wall at a customer site where we went through an event storming session and what you end up seeing is these business events these past tense business events tend to cluster in logical areas around logical aggregates which are you know maybe something like customer or prospect and by clustering these events you can start driving out what the actual domains themselves are for your applications and then we can start drilling down into each of those domains or applications that you have in your existing infrastructure and do what we call a snap analysis where we we just drill down so the whole process is like layering you start at a top layer and then you start drilling down to get information from your application that you re platforming for example and drive out stories to how you get there or you may do an enhanced snap analysis which is something where we're using this for new applications or modern where we're modernizing applications what are the API is how are we going to store this data in this particular microservice and so on so by using stickies and paper we found that that makes it easy to drive out something like this which I call a Boris diagram but it's a spider diagram that shows the relationship between all the domains and subdomains that we drove out through this two-day session where we're event storming and this is actually very useful to have any tangible on the wall kind of structure as opposed to in a Visio diagram because you'll the whole team will stand up and we'll just talk through you know what happens in this case and what happens in that case and it makes it really easy to drive out which application to modernize first which components and how to put those pieces in to make it to make it useful we'll use test-driven development as where as we're going through the process and this book here back if you're interested in TDD it's it's kind of the Bible the reference for test-driven development and but basically what we're trying to do is make sure anything that we do any code that we touch is fairly tested before we even try to deploy it and that simplifies your your process but one of the most important things that we do in this is looking at finding scenes in our application and a seam in this case is basically something that we can do to pull out a new context out of your monolith but still have your legacy big ball of mud work in in this case you can see where we pulled out some functionality from from the left side that we called the new context and we still have to have all of the existing business functionality working so we'll put in these anti-corruption layers and use different kinds of control patterns like event jumping if it's an event based system we'll just route events to the new system or the new components and sometimes it's ugly at first but it's done to enable but one of the other pieces that's important to this is is you'll see one of the bottom control pattern patterns is an edge gateway and Apogee is an example of how we can from the API level control access to both these new contacts and the old context and keep your business up and running while you're doing it or iterative deployment so every two weeks or every week we may have a new deployment of this new context but we want to make sure that the only change we have to make if anything is to our edge gateway to route traffic to the new service and prep all you're going to be talking more detail about that in a minute and then the last thing is by having that finding those themes in your application it enables you to iterate as opposed to do six-month projects so we succeed fast fail fast we can be innovative because we have small groups and small teams they're solving the particular problem the best for that problem as opposed to because the standards they do it this way and then of course requirements change all the time and the last bullet on theirs is by pairing as we're writing it it enables development team mitosis so we can have cross-training between our teams on a weekly level as opposed to writing giant run books and you know going down the path of you know documentation that people won't read it's all hands on and and developers learn as they go so on that I know we covered that pretty quickly some of the resources that you saw in these slides I would recommend you know go out and do some reading and I'm sure there may be some questions on these topics after afterwards so hopefully I didn't take up too much of your time Chris Paul and you can dig into our API management a little bit more and why that's important yeah no I'm asking between be doing we doing great on time I think there's actually a question which is up there I'm going to read it out loud so I think Shawn that'd be great if you can answer that so a question from one of the participants and I think this question is actually on top of mine or many other attended as well so the question is for enterprise software teams who are struggling to keep a monolith afloat while building new features on it because of business pressure what's a good way to sell a modernization approach to executives without compromising on new features yeah that's a that's a very good question and I think the the easiest way that I've I've seen when we're talking to especially executives is you're looking at with with the monolith you know first you have to decide is do we want it to go away and if the answer is yes at some point the monolith has to go away you have two choices you either do a big bang approach where you essentially rewrite the entire model F while the existing monolith is still running the business and then six months to a year two years down the road you deploy that and that's not really feasible because there's always changing business requirements how do you keep them in sync and so by by explaining how we can carve out chunks and find the seams in your monolith and start pulling those out it's much easier to swallow where you're investing small bits at a time and you're seeing quick results and that that's the biggest key is you know in two weeks I can show you honest results that are input action it may not be solving all your problems but at least it's better than it was and we go through that iteration path so there's there's no surprise and you can react quickly excellent excellent awesome all right so so thanks for walking us through some of the decision-making some of the design patterns and process patterns rather and you know how you you know go from read platforming to modernization so let's let's now maybe shift the focus to APM management and what role does that potentially play in an AB modernization strategy so we we talked to several customers and this question actually comes up quite a bit as you mentioned in your earlier slides and materials shown that while people are modernizing apps they're leveraging micro-services as a strategy to kind of break down the monolith right so we see many of our customers you know have an expression what are some of the differences I mean are they mutually exclusive or API then Microsoft is actually complementary so in our experience they're actually very complementary and I think the the semantics of how they are complementary is manifested in how people end up using those kind of capabilities so let's examine a very quick very quickly let's examine a motor with e-commerce system which may be built you know years back but has some kind of a API endpoint to it maybe there's some kind of metal where technologies in there some kind of ESB but there is an API endpoint which is the contract by which consumers use it more of it we feel and we see this thing commonly across many customers that ask micro sources continue to be ramped up and developed there are going to be failures in their lifecycle where they have to be exchanged outside the departmental boundaries in some cases some of those micro services also are offered up as capabilities by the enterprise across the enterprise boundary right maybe to partners may be powering mobile apps and we feel that the API oriented in exporting the micro service has its salient benefits such as you know the ability to first off shield the complexity from consumers so what do I really mean by when I say that what we mean by that is at the end of the day as Yuri platforming and you're moving towards a micro services there's architecture the API helps you set up a nice clean contract which consumers in just gets mobile apps your partners or some Silvan developers can get used to can get acclimatized to and start using it to access the micro services so it helps you shield you know the Microsoft is complexity because let's face it in real life as you going from one list to micro services and you read they're forming and then you're modernizing that are going to be phases in your life cycle where business as usual has to continue even though ID is transforming itself some some of those aspects are under option the other aspect on the the installation process that we talked about out here is with an API endpoint you have the ability to be able to make changes at your own pace with your micro services so that becomes a very very important of paradigm now as as you know in your experience we see with customers that the whole micro services space is exploring many many customers many enterprises have taken to building out micro services and what that means is that although the micro service strategy micro services strategy is a good one obviously it will lead to some kind of issues so what the fourth one we see is with more number of micro services comes more number of API and that is - what we call staps prop and essentially what we mean up there is it becomes difficult to find those api's more importantly reuse is another important aspect and the yesteryear we've seen a lot of different team building out potentially the exact same service right if you don't have an effect we use mechanism or a discovery mechanism it becomes extremely difficult to ensure that everyone else is getting value from the same micro-service the other domain of issues we normally see his cyber threats right so many times when we talk to different kinds of developers including cloud foundry developers they are focused on pushing out quality code which normally represents some kind of business logic component that they have worked on naturally they will have the ability to be able to think about all cross-cutting concerns so the last thing you want to happen is have a great micro service out there but not have the right security control yet right that becomes very important and last but not the least many times we see customers asking us you know how do I really measure if my microfilter strategy is working if we are going to have modernization effort how do we know that that effort that program is successful right and we also find that the existing tools do not provide the right kind of visibility into the use and the performance of the micro services so what is the fpg bring to the table well Apogee has an ADF platform it has been powering many ABI programs on the planet we've been around for a long time obviously part of Google now and we continue to grow the number of customers on a daily basis and if you look at the platform it's a highly distributed scalable purpose-built API platform which can work completely in the cloud so we offer it as a software as a service our customers can run it completely on-premises so the single codebase so they have the choice of digging the exact same software that we hope for our customers they can deploy it in de niro centers across multiple data centers and active-active setups or they can actually leverage in a hybrid model where most of the other services such as the management the developer portal the analytics could be in the cloud and we could distribute the gateways and data centers to support a variety different kinds of deployment models so that's the technology powering the apogee API platform ok so let's take a quick and some of the high-level services one of the differentiators from from an app from a AP mm mm mm perspective is the comprehensiveness of all the capabilities that we offer so again we're not going to spend time going through each one of them but you can see this is a pretty big pie chart of the different functional areas so the security be at runtime that's the gateway layer we can see we have all 30 different or the box policies to be able to think such as traffic management which means let's say you have 10 micro services or hundred micro services and you want to assign some kind of a quota and turns out how much of that do people use maybe there's types of Sun compass some kind of subscription model you can very easily quickly throw in a quota policy which will automatically for all the API exposed by the micro services ensure that only the fair share of usage and gets allowed on those micro services quite that's one example of traffic management then we have in a different kind of policies for security if you want to secure everything using OAuth samo you know controller set of IP address ranges spread protection etc we also have function categories around mediation transformations so 30 different out of the box policies to pretty much do a broad base set of things with API and more importantly the platform is extensible so what that means is if none of the policy that we offer are enough for our customers they can actually use the platform and go and alter their own policies so that's the lower level of the stack higher up as you can see the different categories are there you see the the developer aspect of it which means an API photo through which app developers can come in and discover the API they can use them they can build apps against them analytics give you the end-to-end visibility into the entire API program whether your focus seems to be operational nature if it is business metrics or developer engagement metrics you have the entrant visibility okay so it's a very comprehensive APM and platform and we have many customers who use this thing you look back from a long with bit of dark laundry one of the things that that we try to do is we're iterating building software and modernizing the monolith is we may have cases where we want to do some sort of canary testing for example where here's here's the new you know the new modern part of the application but we don't necessarily want to turn it on to all the end users at the same time as that is that where you would use the throttling to be able to route some to the canary test you know to the new app and then have everything else routed to the existing systems yes I think what you're describing is something more in the lines of Bluegreen deployments if you would write in this cases when we talk about throttling I think there are two different flavors to it Shawn one is where customers want to do generic system-wide spike arrest so as an example many of your customers that we talked to have use cases where they may say you know really on the back end of things when appropriate request to our API we can only process hundred transactions per second that's our limit of how we have deployed in general so they could very well use a spike rest policy to say great just cap that limit and the apogee platform just by the virtue of them adding this policy will automatically throttle the request and not let anything more than hundred connections per second go to the backend that's one kind of traffic management the other kind of traffic management that we see it on distributed coders which means they can essentially within the Apogee ecosystem you can create what we call as a bi products an API products are nothing but a collection or grouping of certain kind of API which can be shaped of towards the consumption patterns so let's example and one example is you could have an employee silver product and employees gold product and really what you're saying is the employees silver product will give you read-only access to all the employee and some other account API and maybe you can access them at 100 times a minute and you can consider an employee's gold product which gives you full crud access twice the full read/write update delete access to the employee API and it gives you access to for other a beard along with it and oh by the way you can use them at hundred times per second quarter right so quota is a second kind of traffic management where customers usually we've seen you know different kinds of customers they may have their subscription naming systems right or they can use monetization capabilities which are provided by Apogee but in either case the quota policy can help them enforce some kind of user base semantics we do have support for Bluegreen deployments as well where we may have certain set of customers where have you mentioned Sean where hey I have a new release which is coming out there but we only want to be able to route maybe the same person or project out there right now and see how that goes is slowly move them over to version 1.1 completely at a specific ramp at some time so let's talk about you know we looked at what the abbey platform is and the capabilities of that so after you provide the API layer for micro services right if you looked at the technology you looked at the gateway we have all kinds of capabilities within the glade gateway on a platform to be able to provide ATM management and we learn to sing early on in fact we've had a hybrid architecture for more than two years where we have what we call as the enterprise gateway so this is the gateway which is used by our customers in the cloud or on premises and Apogee has also had a micro gateway which is purpose-built and shape for micro services so with the micro gateway customers can use us in the cloud completely and they can deploy these micro gateways in their own data centers especially for protecting their micro services and also for use gives their either those API cannot be exposed in a cloud or they have some kind of specific latency concerns these are some great deployment choices which our customers can leverage today so listen about what we'll be talking about carrillo we've been talking about Apogee so what have we been doing together let's say spend a few minutes out here walking through some of the interesting things that the companies have been doing so if you go to a pivotal site today you know they list six strategic partners epi in part of Google so we are two out of the six strategic partner that they will work with we've had a long-standing relationship with Vince a little we've had integrations which we have rolled out the last couple years at different dimensions so first off we have any greater level for us what does that mean that means if you happen to be a pivotal Cloud Foundry customer and if you are an Apogee edge customer you can leverage two of the key integration that we've built so the first integration is in the area of route services if you're a pivotal customer today and you're using Apogee edge you can go to the pivotal network at network of pivot or IO and download the app agh service broker tile and that works whether you're using a page in the cloud or a PGH on-premises so you can use a service broker to provide ABM management it uses as out services capabilities and then for customers who are deploying Cloud Foundry in their own data centers or on some kind of public cloud we actually also have a bortion sort of refugee edge which means the same kind of benefits that they leverage and get from Bosh for managing maintaining and healing pillow-talk laundry in the same way the Boston storage will help deploy you can deploy a pg8 through boss on a separate set of VM and Bosh will manage all the you know instances it will draw the same benefits of management maintenance and healing there is a tutorial for bid today if you double-click a little bit on some of the integrations options that we just spoke about so the first integration option is for all services in this case you can use a bgh Enterprise whether that happens to be in the cloud or on premises and you can use the routes ocean based integration which is delivered through the service broker to provide ATM management for micro services option number two still leverages the exact same service broker still uses all services but is more purpose-built in leveraging the FH micro gateway so in this case the micro gate we're actually running addict Cloud Foundry app natively on the platform and you can use the micro gateway to protect your ap to protect your micro services you know provide traffic management security and it pushes analytics into the cloud so it becomes a great deployment option for customers who are looking at that a third one which has actually we've seen a resurgence of this ever since privilege boundary and power phone we announced the medical bag this is available today for customers as an open source solution but we have to be working in the park trying to roll this thing out in this case this is a great way to actually distribute the ad vgh micro gateway into the PCs apps and China this is a pretty interesting to Blauman patent and the reason for that is it makes it easy to now have the VCF app secure absolute right so the previous two models are more like a proxy model where the request gets intercepted it's it's processed by Apogee and then goes to the app in this case there is no routing overhead there is no doubt sources needed and the request comes in directly from cloud following to that app and epi 8 micro gateway which is embedded as part of the container can actually provide traffic management security and pushes analytics up to the cloud so with that I want to talk about a customer use case which have been very representative of many questions which many other customers have around have modernization but I'll read that forming t-mobile is being a marquee customer both for Apogee and develop out boundary and maybe their journey they've been on a journey of app modernization for some time as you know this is representative of many others significant enterprise customers where they have a lot of investment in on premise of system legacy apps which continue to be out there and now they are on a path to modernize some of these apps as micro-services and they're using every edge at the API moment here to be successful with the app modernization efforts so Shaun I'm going to kind of Mary do you know just converse a little little bit got into the very very important for customers to hear some of your one personal experience when you work with t-mobile and you know there are the idea of different kinds of use cases that we are solving but of particular interest to me is the user services can use get could you walk us through you know what the disk is is what the journey has been like and how they're using you know total Cloud Foundry for obviously deploying those new micro services but also importantly using API management and a strategy for insulating themselves against many of the things that day would paint otherwise just your thoughts you know what has been your experience sure so just a high-level overview at t-mobile we were trying to do what I just described earlier strangling the model is right pulling out some of the domains and services out of out of their existing enterprise and one of those was customer usage so something as simple as you as a t-mobile customer want to see you know how many minutes you've used or how much data you've used or you know this this old system even kept track of you know how many text messages when they used to build for that and all of that information is is out there and something that wasn't incredibly difficult to to pull out of the monolith but where it was difficult is there's a lot of business partners that t-mobile has that are not part of t-mobile you know they may be third-party resellers you know like a Walmart or something like that and the the interface that they expect to see for that usage service for example for their applications that they use when they're selling t-mobile plans to their customers it is a very tightly defined API and it was unreal able to expect that as we are changing the back end to make usage service you know more modernized and rest-based and and using choreography instead of orchestration all of that needed to still be independent both security wise and from an API perspective from the partners and so that's where Apogee came in to make it easy to take the existing interfaces that the partners already expect to see and then do the appropriate calls to the micro services and that translation in between and also handle the security for us so so it made it really simple for a development team to be isolated from you know the end use of the application and decouple that because Apogee was handling all of that excellent excellent so the other question which comes up and I've seen you know customers kind of sending many other customers can kind of benefit from that as well one of the key benefits of this kind of a strategy by leveraging a DM management is you know they've been able to answer questions like well great we put you know micro sources to work we are modernizing our haps but how do you really know what the customers are doing price in this case some of these developers and architects are team over there are spoken to they you will be a bi analytics offered by Apogee edge as a great a system of record if you would or source of proof if you would to see what percentage of traffic is still continue to go to the legacy apps and what percent of traffic is now moving towards or being served by micro services so in many instances they are actually using you know those kind of that kind of data to be able to make some decision points right how do the other teams accelerate to move on to micro services that seems to have worked out really well for them you know we have many other customers who are very similar shoes and are getting the same kind of benefit so with that let's kind of move towards the cloud here so obviously with the integration that happily provides to pull out boundary there are several benefits that are passed on both the developers and operators right as we discussed earlier we use a lot of different out-of-the-box policies which are they with an at the end to provide things such as traffic management and security capability to the ATS and microservices you can also vote Rheem and then use some of the monetization capabilities which are also built into the APD platform to you know if that's the more of the work for you to start making money on your API right you have lots of other kind of abilities such as developer portal to ensure that you know upstream adoption of the micro services is triggered by you know mobile apps or any other apps by partners having built the developer portal gives them that kind of capability to be able to go in and you know understand how the API workers are using them obviously from an algorithm perspective we have different kind of deployment patterns a pH could be a layer setting complete in front as you saw on the last slide you can also use it through rock services to leave an API management as you need to and with the meta built bag deployment model you can distribute API management and runtime embedded into the PC web containers more importantly for customers who are you know maintaining and managing their own PDF deployment through Bosh they can also leverage the Apogee edge borsch installer for doing that kind of you know self-healing management maintenance etc so a lot of benefits for developers and operators and you know ultimately we've been talking about this for a long time it really powers the data value chain right so anything that's being built has to have a consumption focus and you can see with what Shawn presented today Cloud Foundry pivotal Cloud Foundry is a great cloud native platform which gives the ability to rapidly build these services like you micro services which power different kinds of experiences the Apogee API platform FPGA edge will give the ability for you to be able to take your baby eyes manage them provide some extremely curated experiences delivered through the app to the end-users so this is a great win-win combination and want to highlight some key takeaways for our attendees today so I'll let you take the first to Sean if you just want to hit on them and then I'll talk about the remainder three so the first takeaway is modernizing your applications can have a huge return on the investment and to add on that it doesn't necessarily mean it it's a huge risk upfront and a huge reward at the end by using the techniques we talked about here you can you can modernize your applications incrementally and you know see it start to pay for itself over time and that kind of leads to the second piece where it doesn't have to be hard that's the whole key to this where the reason people don't start this is because they have a big giant monolith and it's like your teenage you're trying to clean the room you don't know where to start and so in this case we're saying just go to the corner and start focusing on one small thing and and build your application iteratively and that's how you eat that elephant one bite at a time I think that's a great analogy I think the the analogy that you use out there and I think that's that in a kind of what we see as well in many of our existing customer base right but most of the customers don't have a very successful and thriving API program it's all about think that one use case that high-touch high visible a use case to all the ocean start rolling out you know a vm element on top of that and start to get some benefits right so those are quick win for many enterprises so so the other takeaways that will call out is as we saw APR the micro social complimentary right shape we enjoyed a great mechanism to choose the complexity it's the way that you want to expose your micro services and many of the benefits are automatic as to you then you talk about strategy and we look at the team of an example just like it's working for them the same strategy is working for many other customers right you the API management edit transition to micro services so it can help you insulate and buffer the complexity that you dealing with on the right hand side which is taking the existing monolith or legacy S & fu morphing them into modern micro services having an APM and as a layer will give you that insulation to continue doing business as usual continue meeting your escalate with your customers that's the most important thing right and we have several examples of other enterprise customers who are using this approach successfully today so hopefully that was helpful for you hopefully all the attendees learned something from the webinar I can be read at at my twitter handle at debug yo and we'll we'll be around here and maybe answer some of the questions which came up so I think we still have a few more minutes if you have an ask you a question go ahead and add that on the on the question panel and then we'll we will start answering those questions as they come along but Shawn I really want to take the opportunity to thank you for contributing to this webinar I think this has been a topic of pretty good interest amongst many customers many questions which I think hopefully got answered today but some of the material that we covered and hopefully they're able to take these kind of design patterns in the decision-making and use some other technique that you described to be able to justify you know the value of f modernization and how they can use ABM animated strategy to be successful in that initiative so once again thanks for your time and we really appreciate all the attendees for taking the time or the busy day and attending this thanks so much and it will have the slides which will be posted and email to you within the next week or so thank you you

Channel: Apigee

Views: 2,520

Rating: 5 out of 5

Keywords: api, app modernization, microservices, pivotal cloud foundry, pcf, apigee, api management

Id: KxDmR6K0Wbc

Length: 53min 20sec (3200 seconds)

Published: Wed Aug 02 2017