How NextGen Healthcare uses AWS to deliver better services

good morning, everyone. thanks for joining our session. this is ent 216 in the migrations and modernization track. uh we are going to be talking about uh how next healthcare it leverages aws to deliver better business outcomes for providers and patients. uh before we get started, i want to quickly introduce myself.

my name is anand iyer. i'm a principal solutions architect at aws. i've been with aws for a little over six years now and over the last three years or so, i've been working with nextgen healthcare on advising them sharing best practices on the migrations and modernization journey.

um i know steve and i are standing between you and lunch. so i want to make sure that this is time well spent with us and we want to share some of the learnings and the best practices and the approaches that we used for the migration and modernization.

um so without further ado, i want to hand it off to, i guess to here.

hi, i'm steve ruiz. i'm a vp of devops and nextgen healthcare. my team and i act as an agent of cultural change for our engineering teams and we provide subject matter expertise and tooling for application delivery on aws.

so why are you here today? uh you're probably at some point along your aws cloud journey. you could be considering a move to the cloud, uh what it might look like and how you might approach it. uh you've started your journey and you've had some successes in pitfalls and looking for a better path forward or you're a, you know, you're a mature builder on aws and you're looking to experience an insight from others. we'll share approaches examples and lessons learned from migration to and building upon aws.

so, nextgen healthcare is a leading provider of innovative health care technology solutions on a mission to improve the lives of those who practice medicine and their patients. so we believe we aim for better health care outcomes for all both those providing care and patients like you and me.

um our focus is on providing a complete offering to our clients. this is a, this highlights a few of our solutions we provide and at our core across our enterprise and office pillars, we provide clinical care, practice management and patient engagement solutions. at a basic level, we help our clients uh providers, doctors offices, ability to manage their business, to provide care to their patients and to communicate with their patients. and within our insights pillar, we offer solutions that facilitate data exchange and interoperability among disparate systems and analytics and care management solutions that enable the transition to value based care.

so this is a small peak into our technology landscape at nextgen healthcare. um it might not look exactly like yours. you probably have something similar in terms of variety. uh nextgen has grown a lot over the years through acquisition and we have a diverse set of technologies across your pro products that you can see here. uh a number of them are built on microsoft technologies, but we've had different teams over time building products, uh different time frames that they were built. um we have legacy applications developed many years ago and applications that were born in aws with modern architecture. so we don't have a core technology stack that, that everything is built upon in nextgen.

so we, we started and continue our journey with a core set of challenges and goals that are shown here. uh i expect a lot of you face uh some of the same challenges and goals.

um but we were lacking agility to respond to, you know, customer demand. if we wanted to poc something quickly that could be held up by a ticket to our it department uh maintaining and deploying our application infrastructure uh led to a lot of operational burden in our data centers. um our customers were impacted by issues with the availability of our products and reliability of our products in the data center. when you have a lot of different data centers, a lot of different acquisitions, there's a lot of little pieces that probably don't get the attention that they deserve.

um we spend a lot of money and time staffing for unique skills. so if you've got a per one network vendor in one data center, you need someone that's an expert on that and that doesn't scale very well. we're also worried about capacity and growth. what if, what if one of our products really took off? how would we address that?

and to solve these challenges, we set forth a set of key goals. we wanted to demystify our application, infrastructure and configuration. you know, we had some older legacy applications running on older infrastructure, um handcrafted and configured by people who may have no longer been there at the company. so we wanted to solve for that.

we wanted to remove single points of failure where one piece of hardware, one service, one location could cause impact to our customers. and we wanted to bring some standardization and economy of scale to our varied technology landscape. if we can't, if we can align on data stores and programming languages. and the like, you know, at least we need to have a common language. we speak across products in a platform to build upon.

we needed to improve compliance and security. you know, we're, we're a health care company company, we handle patient records and data. so we wanted a common platform on which to build and a common set of tools to control remediate and report on security findings.

cost management is always top of the mind. when we're migrating to aws, we need to keep an eye. it's on our costs. so we need something to uh alert and do capacity planning and forecast and track our metrics.

um we wanted to bring our staff along for the ride. we needed to make sure that we were upscaling our staff. um it's very expensive to hire a whole bunch of ews experienced engineers. so we needed to ensure that we brought everybody along for the journey in that transition.

um your journey may look similar or just be starting, but this is a little peak of ours. um it's, it's long and it's never ending. it's always evolving, but this is what it looked like for us.

you know, we had some initial aws adoption in the early days. um we started using things like ec2, uh s3 and simple db. uh we kind of uh a few of our product teams peppered that inside their applications, but things really took off in 2015, we started using aws as a primary platform.

um we started migrations in bulk of clients and our products into aws and we uh started the development of some of two key aws only sass only products in aws, our population health suite and helped five years ago, we built out our account landing zone and and guard rails that i'll talk about more later and four years ago, in 2018, we made the decision to go all in with aws. our aim was to close out all of our data centers build on aws, focus on aws managed services. and at present day, we've closed 13 of our data centers and we're working on the last three before we get into the details of how that's gone and what we've learned.

i'm gonna pass it over to non to discuss the three keys to migration and modernization success.

thanks steve. so as you heard steve talk about um next gen specific challenges and goals. i want to kind of put some context around what are the key business drivers that i see specifically interacting with customers around migration to the cloud and quick show of hands. which one of these do you see in your organizations today? if you have been migrating on the cloud or are thinking of migrating to the cloud, you may see one of these patterns that are kind of drivers for you.

and so the initial drivers to the cloud were very much focused on cost. so if you look at cost reduction, if you look at data center consolidation or outsourcing changes because of end of life of hardware or software, those were the primary drivers until now for a lot of customers. and obviously, customers have realized cost savings either by right sizing instances, looking at de test environment, shutting them down, building automation in place, but those are table space.

now, i don't think customers are thinking about just moving to the cloud for looking at better performance or cost advantages. right? there are two key factors or vectors along which i basically have conversations with customers around migration to the cloud.

the first is clearly lift and shift kind of migrations just doing data center consolidations. but the second is along the innovation vector, essentially looking at enabling new capabilities that you don't have today or looking at agility and staff productivity that you want to build into to your workforce implementing new models of delivery. and we call that through digital transformation, digital initiatives that kind of are longer cycles maybe today for you. but you want to do enable experimentation or try out new services.

and so as more and more customers are looking at cloud adoption, you want to think about not only just migrations but also about modernization. and i want to introduce a framework to think about large scale migrations and modernizations because most customers like you talked about, they usually start off with experimentation, right? they started off with experimenting with aws in 2010. but then in 2015, the first few years, they spend time thinking about projects.

so the typical kind of cloud adoption model or cloud maturity model that you see in enterprises is usually start with a project phase. i pick a few projects. i try out those projects on aws, learn from those projects and then over the next phase, you start looking at the maturity, you start looking at foundations. how do i start organizing my accounts? how do i start organizing governance?

and if you think about the cloud adoption framework, it gives you a very nice prescriptive guidance to think between business, between platform between people governance, security operations. and those are the key six pillars that you want to start thinking about as you get into the foundation space.

once you are in the foundation phase, you have set up the right car rails in place, then you start thinking about large scale migrations. you want to start thinking about applications, how am i going to take these applications? do the wave planning and get into the migration space?

and now we have migrated to the cloud. it's not, it's not done and dusted

It's a journey as you get into the cloud. You start, you're going to start thinking about what are some of the applications that I want to start modernizing? Now, what is that cloud native or cloud maturity model that I want to aim for and organize my teams, my processes, my technology around it?

And so that's where the six hours of migration really become critical for you to start thinking about. And AWS obviously has a methodology around this process. And I'll talk about the framework and how we can leverage the six hours to start thinking about enabling large scale migrations.

The first R is around Retainer. How many of you actually have seen this pattern? Any? Ok. So few of you have seen this pattern. But I want to talk about what do these Rs really mean? The first one is Retain - some applications that you want to retain in your on premises environment. Um maybe they are not apt for the cloud things like I work with life sciences customers, they obviously have labs, lab systems, those are not things that you want to move to the cloud, but you want to integrate those into the cloud.

Second is Retiring systems. Steve and I, we were talking about an application that was built in the 1970s. They're still operating, they have, you know, uh providers who are using those applications. But do you want to really take an application that was written in the 1970s where you probably don't have the source code to be able to support? Do you want to retire them or do you want to um kind of gradually phase them out? So start bucketing your applications in this Retail and Retire.

The second is the third is Re-hosts which is taking an application that's running today has some rough edges. You want to probably think about a AWS well architected framework to start honing in on what are the key pain points that that application has today. You obviously don't have the budget to go redesign and modernize their application, but clearly there are some pain points that you're looking to address. Maybe it's around availability, maybe it's around operations, maybe it's around performance are these things that are really important for your business users and you have the right stakeholders in place to be able to get sponsorship to do a re-hosts of that application.

Re-platform essentially means looking at an operating system or a database and moving to an open source or moving the operating system, let's say from a Windows operating system, if you are really thinking about moving out of Windows or thinking about a managed database, you know, these are kind of replat phase applications.

And then there is the Refactor phase which is I want to kind of look at this application uh not completely rewrite the application, but maybe use some native cloud constructs. For example, you may have queues that you are using and you want to use an AWS managed queue service or you want to have some kind of a batching functionality that you're using and you want to augment it with more scalable practices using AWS batch specific services.

And then the final phase is the Re-architecting phase which is kind of, you know, I want to completely redesign, refactor, modernize this application build something which is completely maybe serverless or take advantage of the cloud capabilities to make it on a pay as you go approach. All of these are again, critical considerations for you. As you start thinking about formalizing your migration process and from hundreds and thousands of engagements that we have done, we've kind of formalized these patterns now and giving prescriptive guidance to customers on how they should think about the successes and set themselves up for success.

So I'm going to, I'm going to talk about the three keys to migrations and modernization. The first one obviously is having a clear plan, right? Without um there's that saying about, you know, you measure twice, cut, once, right? So you want to make sure that you have a clear plan around your application landscape. Some of you probably have this really figured out in terms of having an application landscape which covers everything from a CMDB to an Excel spreadsheet to, you know, exhaustive techniques that you have used to collect all of the application landscape that you have.

So making a plan of the application portfolio really involves a critical piece which is assessing all of your application landscape using either AWS tools or using your internal tools. Once you have analyzed your landscape, you want to start thinking about how do you want to bucket these into different hours that we talked about? You may start thinking about retiring some of the applications. And from the experience that we have, we usually see about 10% of these applications get retired customers don't want to move those applications and they are ok keeping them wherever they are because they have a clear path for end of life.

About 20% of these applications, they end up moving into a SaaS model. You may be using some sort of a security tool, whether it's a monitoring environment, whether it's a network monitoring application, monitoring on AWS, you have the choice of hundreds of partners, whether it's the marketplace to choose some of these models, to be able to deliver the software as a service rather than you maintaining it today. Or it may be a homegrown system that you are looking to retire.

About 50% of these applications end up being in the the second bucket, which is the Lift and Shift and Replat. So the Lift and Shift is essentially just taking the way the application is running today and running it on AWS. AWS obviously has several tools that we provide you to do that. And Steve is going to talk about one of those applications that they started off with, which was a clearly lifted shift, right? They did not want to change a whole lot of application architecture, but they did have certain pain points that they were looking to address. And so identifying those pain points is extremely critical when you think about any of these application migration patterns. What is the clear business value that you're going to deliver to your end customers? Is it around security? Is it around cost? Is it around performance? Is it around operations. Is it around reliability, identifying that having the right stakeholders and delivering the migration to achieve those specific business outcomes, we really accelerate your journey to the cloud.

Second is around Replat we talked about different patterns around Replat, not really changing the application so much, but taking advantage of AWS managed services to really remove the underlying heavy lifting that your teams might be doing some specific pain points that we see with customers is their own databases, database management. The patching of those databases, the backup of those databases recreating environments, those can be real pain points. And as much as possible if you want to use AWS manage services, whether it's an Aurora database or whether it's a managed RDS database, all of those have capabilities for you to deliver that incremental value to your end users to your business users. And now they see the benefits actually moving to the cloud and the third phase, which is about 20% of our customers applications that we see are in the transform phase, which is like we talked about an application that really maybe it's a batch oriented application, a document generation, batch application which takes a lot of time is brittle, it breaks every night. And now you want to take this opportunity to really transform that application.

There are newer model models to build using AWS services, whether it's a serverless or whether it's based on containers, but it's about 20% of these, right? But as you migrate these applications and as you start building this plan, you want to have a clear structure. At what point are you going to start continuously refactoring these applications? Because at the end of the day, you don't want to just go on the cloud and operate the way you're operating on premises. What additional business value are you delivering to your end users?

Now, this is an extremely important point which is you created this plan thinking about those cloud adoption framework that I talked about, right, the six perspectives around people platform, business, security operations governance. This is the governance and operations piece having a clear plan around day two operations and not operating in silos about you did this migration and but you are not prepared on who is going to be able to support this application.

Um Steve will talk about what model have they built, right? Having a platform engineering team which is responsible for setting up the governor, the security guard rails and then enabling the app teams to migrate applications to refactor applications. But at the end of the day, the app teams are the ones who know their applications the best. What's the operation, the support model. So building an operation model and a service management framework is extremely critical for you to do this.

And selecting an operation model is also important depending on what your skills are, where your constraints are, what resources exist you have again three different options here at connection health care. They have chosen the self managed option, which is like he said, we wanted to build skills, we want to enable our teams to be able to do this and build that muscle. So with that, you can still provide things like self-service capabilities to developers to be able to create dev environments, test environments. Uh QA, you know, system performance test, SVT environments, verification environments using service catalog or you want to use AWS managed tools.

There's a whole lot of security tooling that's available, whether it's using GuardDuty for protection, whether it's modeling and provisioning of environments. Um automation and infrastructure escort is an extremely key component of doing this at scale. Um and then finally, monitoring and logging, Steve will be talking about um specific monitoring and logging, uh tools that they have built to be able to take all of the logs from various different accounts, AWS accounts, stream it to a centralized account. So you have central visibility, auditability and control.

On the other end, you also have customers who choose to have a lean model, which is operate through a partner, which is a partner managed model, but you have an MSP or managed services partner who is kind of managing this for you, right? Because your IT teams are either too busy to be able to take on this additional work or you can augment them. And then in the middle. There is also this option of AWS managed services a SAMs is an out of the box cloud operating model. And what that allows you to do is not have teams focused on doing the patching of those two systems. Um building all the pipelines to be able to do the automation. So AWS managed services, it addresses the security and compliance and AWS kind of takes on that heavy lifting from your team. Of course, AWS is not managing the application for you. This is not application support, it is the underlying infrastructure support.

Um there is self service automation capabilities that are built in AWS managed services and it gives you a quick ramp sort of in a month to month until you build your own capabilities in house.

Now, one of the key things as you start thinking about putting together the structure in place is identifying the key technical and IT domains to modernize. And as customers start thinking about these, they usually start off with things like virtual machines, standardization of environments operating systems. You may have a sprawl of various versions of Windows, various versions of Linux, various flavors of Su and Sento and Debian distributions. How do I want to make sure that I provide repeatable environments that I can manage for the various IT, various application teams. But at the same time, I can, I can make sure that, you know, I have control and I don't have and I have guardrails and governance in place.

The second aspect they look at is around custom, around security and identity management. What is my identity strategy for managing resources in AWS or even managing application authentication is SSO my central place through which I'm going to access resources, AWS SSO for applications. Is it AWS Amazon Cognito or is it going to be Octa? You may already have business applications that are integrated with Octa. I think there are multiple choices there but having that kind of thought process in place will really help you scale your migration and modernization journey.

Third is around storage and database tools. We hear a lot from customers around various different tools that are used for storage specifically around you know, storing things forever, right? Having the right life cycle policies in place even in the health care industry where you need to store certain records for seven years or 10 years and using maybe a AWS Backup or a storage service to do that.

We talked about monitoring and control mechanisms which is using monitoring tools using modern monitoring tools, whether it's using AWS managed services or through a marketplace offering, whether it's through a partner offering. But ensuring that if you want to use existing tools and keep those skills in place. But at the same time, use something from uh from a from a marketplace offering.

And the last point is again, an extremely important one which is around training and learning new skills and tools. This is something that is kind of as an afterthought. That's broaden putting formal guidance in place internally, whether it's through uh proper formal AWS training mechanisms or training the trainer or make making access in place that is imparting and you know, getting that skills and knowledge across different application teams is critical to success.

The third phase is Iterate, learn and repeat. It's never every customer's migration journey is going to be unique. It's not going to be a cookie cutter pattern, right? For everybody. But what you will learn, I worked with customers who have chosen this in a bite sized approach. They have said I have these 30 applications. I'm gonna kind of bucket them into re-hosts and replat not gonna touch anything that is a factor right now. I want to have a time bound manner in which I put a plan in place to migrate these applications and learn what my experience is.

I want to understand what are the dependencies of this application. How many times do we discover applications where you have a database that shared by multiple applications? And when you are thinking about putting together your migration plan, you want to make sure that the dependencies are taken into consideration. Otherwise some applications will have a great experience and the others will suffer.

And so cost also becomes an important consideration because if you are, if you have a shared database and you don't want to split that database now and increase the cost of operations for a particular business application. So making sure that you are learning and creating these patterns and disseminating those patterns across different teams can help you scale again.

Um I want to now hand it off to Steve on how they applied some of these learnings. They may not have formally applied it, but as they were applying it, they realized that, you know, we use this pattern and this pattern helped us discover some of the gaps in migration and they addressed it in the next phase of migration. So Steve thanks Anan.

So we'll walk through some examples of migrations we've done along our journey uh generally in order of time and maturity. I i would caution that we, we have uh architecture diagrams up here, but I'm not gonna go into detail into the architecture of applications. They're generally condensed, they don't contain the whole thing, but they just provide an illustration for the story that we're talking about here.

So as Anan said, iterate, you know, pick a small application, try it out and do that first. Um we didn't either hear that advice or get that advice at the time and we picked a giant application to start with. This is our first major migration. Um it was really driven by data center issues, you know, reliability of an older data center and the capacity in that data center of the application.

Um it's, it's a really complex set of services. It's built on a largely Microsoft technology stack - Windows, .NET, SQL Server, a whole bunch of services. Um and we took a lift and shift plus plus approach here. So we, we kept the architecture fundamentally the same and we, but we focused on not migrating any VMs over. We didn't want to take that legacy that was built in the data center and bring that into the cloud.

We took the time to understand the application and automate its deployment. So this, this is the painful thing that I was talking about when you know, engineers who built it and handcrafted it are no longer there. There's a long period of discovery and figuring out how to deploy this application.

So one of the key things, our, our key approach here was automation. We, we started building a set of reusable modular infrastructure as code components um that powered the migration of this application and we continue to iterate upon today. You know, if you need a S3 bucket that's properly encrypted and secured. And with limited access, we have a Terraform module that we built for that.

Um the end result was a stabilization of our reliability challenges. Um we went from some big customer impacting issues with this application in the data center right before our migration. Um and we saw 100% uptime for the month post migration. So we we reduced our operational burden massively.

Um we had more automated deployments. Uh we had self healing infrastructure with auto scaling and, and this is a real success for our customers. If, if I could go back in time and change something, I think our biggest failure here was organizational and cultural.

So we came in as an outside team to start migrating this application into AWS and didn't involve from the start the product development teams or make them accountable. And when we, it made it take a lot longer than it should have. And then when we got into AWS, we were left helping them operate this application, they weren't ready to run with it and, and keep developing new services on their own.

So that was a key learning here and something that we will show you that we fixed in later migrations. So moving up to uh the year 2020 we had our Virtual Visits, project product. Um this is also known as telemedicine.

So we, we had some large migrations behind us and things were moving more smoothly. So this was a smaller acquisition of NextGen Healthcare that we brought them in 2019. And at the time, um it was something that providers or doctors were experimenting with, you know, they were trying to give their patients new options. Let's see how this, you know, I can do telemedicine and give them an option to see me without coming into the office.

And then something interesting happened in 2020 the, the global pandemic. So from being an experiment that, that providers were trying out to be overnight, be a core of their business, you know, this was how they were going to stay open and survive the pandemic.

So we, we had to solve for this. So this product was actually originally built in AWS, but a single account, you know, and uh a smaller team experimenting, they didn't have all the guardrails in place.

So we, we did a, we took a landing zone methodology to rope them in them into our uh account landing zone and guardrails. And uh we implemented infrastructure as code and automated deployments for this. Uh we, we built it in our standard set of separate accounts. You know, we want to separate the blast radius so developers can create development test QA environments, but production sits alone in its own account.

Um we focused on reliability and scalability. You know, we moved from um separate uh single availability zone RDS instances to multi AZ RDS instances. We, we set up uh auto scaling groups so we could automatically self heal and scale to uh handle the load that was coming from our customers.

And then we also looked where we could rope in managed services. So we pulled out a RabbitMQ, our, our self to manage RabbitMQ running on EC2 instances and slightly re-architected our application to use uh AWS SQS and SNS services.

So in the end, we supported 140x growth of that product. Um if I did my math right, that's 14,000% growth over a period of uh I don't know, two months and you know, we were able to deliver that reliably. So we we could automatically scale to, to support the load that, that our customers were seeing.

And this is a migration that we did just this year. So continuing on our journey, we, we wanted uh to modernize this application. So this is our ePrescribing API it's kind of a translation layer between our electronic health care record and uh common ePrescribing vendors in the United States. And it provides an API for them to talk to each other.

So the driver here was also COVID related, you know, we were, we're becoming, we are now a remote first company. We're divesting a lot of our real estate and we wanted to close down this, this data center. And while we're doing it, we want to reduce operational workload.

So this is not a application that changes that often where it's something that has to have that kind of dial tone reliability, but it's not something we're working on all that often. So we wanna make sure that, you know, we don't have to put a lot of effort into operating it.

So we took the opportunity to modernize it. Uh this was a on premise, this was a very standard legacy .NET, uh IIS and SQL Server workload and we moved from .NET to .NET Core. So we tweaked the application a little bit to support that. We made a move from SQL Server to Aurora Postgres. And we, we started leveraging AWS managed services. So Lambda, API Gateway, AWS WAF for security.

And, and in the end, we realized a very uh highly scalable and reliable service in AWS, we, we had reduced effort with uh you know, automated deployments and the ability of our developers to create test environments as they need. Uh we reduced a lot of cost here with uh you know, natively scalable um managed services from AWS.

So we took out Microsoft Windows licensing with that move from .NET to .NET Core and uh SQL Server licensing. So this, this was a big success and again, organizationally and culturally, the uh product development teams were involved from the start. So they were able to actually do a lot of this work without uh the help, much help from an enabling team like ours and run with it post migration.

So the the security of our customers data being a healthcare company is at the forefront of all we do and it's everyone's job and to understand the approach that we take to security, uh it's under important to understand the regulatory environment we we live within in the US healthcare world.

So HIPAA and HITECH are, are two of the main laws that they control the privacy and security of patient data. And 21st Century Cures Act uh controls the uh data exchange and sharing of patient data.

So the key bits of data we protect here are PHI - Protected Health Information and PII - I won't get into the details, but PHI includes things like names, social security numbers, birth dates uh that are used in the course of providing health care services.

To protect our, our customers data, we generally follow these guidelines:

• We assume everything is sensitive. So we're building healthcare software. Our our core focus is you know, patients and doctors. So there's we just assume that every everything has sensitive data instead of categorizing in individually, in this way, we can apply common guardrails across everywhere, everything for instance, make sure that we encrypt everything as a standard.

• It's important to use BAA only services. So um the law requires that any partner of, of a health care provider um processing patient data has to enter into a Business Associates legal agreement and AWS has certain services that are part of that, that Business Associates agreement.

• Back in 2017, that was much more of a concern because there weren't a whole lot of products in that. Um today, it's not so much they generally try to launch with uh with services within the BAA but this is still important to point out.

• We conduct go live and on architectural change reviews, you know, we want to review our applications, assess compliance and audit that we did.

So and we also bring in a third party for assurance that we are doing what we say we are doing. So this is a picture of the uh what I call our account landing zone and guard rails that we put in place and, and I'll take you through that.

Um we, we look at it in several layers. So things like access. How do people get access? How do we provision and control accounts with our landing zone? What detective guard rails do we have in place to, you know, make sure that we're complying with our security standards.

Uh what infrastructures code do we have in place to again enable and iterate our team iterate on things. Um what preventative guard rails do we have in place and what reviews do we do?

So this is the previous state around the time of that first migration in 2017 with our legacy patient portal. So we had a landing zone, we had separate set of aws accounts per workload with some core accounts um for centralized concerns like logging, security, key management and authentication. And at the time, we built our own tooling.

Um aws control tower solution for instance, wasn't ready at that time. So we built our own um we instituted detective guard rails, things like a config and guard duty and with real time alerting solution that we built ourselves. So we take inputs from all those aws security services, channel them through our alerting service and it routes them to the appropriate uh channel in slack.

And we, we leveraged ad hoc prowler stands. So prowler is an open source tool that augments aw s's security and compliance capabilities. It's, it'll be linked in the presentation there. But that's a tool that we, we were using and running manually um with infrastructures code, as i mentioned before, we, we started developing and we continued to develop uh reusable infrastructures, code modules and, and reference architectures and we really focus on compliance as a default.

It, it's pretty difficult to uh you know, it's a lot of work to set up everything and be compliant with all of the, you know, the security requirements of your industry. So if we make these modules and things, we can make it easy for c for our builders to create uh say a s3 bucket that, that ticks all the boxes. It's been one of our uh one of our key learnings along this journey.

So at present state, you know, we've deprecated uh it is a journey. So we've deprecated some of the old stuff we built. So i mentioned that we, we built our own sort of custom landing zone. Well, we've moved over to a w s's control tower. We want to let aws take on that concern.

Um we've adopted octa with uh what's now called the im identity center. I think it used to be called aws sso. And we've improved our detective guardrails. We're started to leverage security hub controls and organizational leverage, organizational level level configurable where we don't have to go apply those to each account and ensure we keep each account up to date. We can, we can handle it at the top level.

We've added a static code analysis within our code pipelines to ensure the security of our applications. And we're now instead of doing manual reviews of, of audits and go live, we're using security hub and quicksight to um surface findings and let us kind of automatically audit our, our products.

And there's some things that we're working on too. So we've adopted control tower, but we don't have a way to automatically provision new aws accounts outside of our own custom developed tooling. So we're moving to aws control tower and account factory.

Um we're continuing to use prowler, but we're automating it to make it continuous. So, prowler will integrate with aws config to give you um you know, security compliance assessments.

Um we're looking to in integrate our run books with uh within our detective guardrails to provide for automatic remediation. You know, if we see something that's put in the wrong uh subnet, we can remediate that and you know, tear it down right away and we're moving static code analysis into our pool request to provide a faster feedback. loop for our developers.

So what's next for us? Um obviously, we're all in with aws cost is, is has been and continues to be a concern. So we're improving our cost optimization and reporting with some cloud intelligence dashboards.

Um we're looking to enhance our, you know, the use of our data. We've we've got a lot of data and we want to unlock the value of it for our business and our customers. So we're building a data platform so secure and scalable access to our, to our data. So we can build benchmarks that enable value based care.

And we're always looking to make a thing to let our builders build with less friction and provide for self service capabilities. So we're doing that in several ways. We continue to build out our platform of our aws account landing zone. We work with aws uh with our solutions architect to get a view of upcoming services and making sure that we're not building stuff that aws is gonna be coming out with. In six months still happens.

Um we were working organizationally to build out our teams. So we're building out a platform team. You know, we, we have our account landing zone, but we're building some higher level platform services that internally teams can consume to power their applications.

Uh we continue to work on our enabling teams, our sort of cloud center of excellence to consult across our application teams and of course, continue to provide training um to our developers to let our little builders build.

So there's some key takeaways and benefits that I'll go over here. If there's one thing that i would say today, it's separate your workloads, you know, have that account infrastructure and guardrails that let people build, you know, securely you, it's very easy to go um off script in aws and do something that has runaway cost or has big security issues.

So if you can build out that account structure to limit what uh in an individual can impact and give them guard rails to do it, right. That's really the key here. So, and I would prioritize preventative guard rails. What we've learned, we, we have detective guard rails that tell you when something's wrong. But if you just don't let it happen in the first place, then you don't have to do work to go remediate that.

So preventative guard rails, even if it's a little bit more friction upfront and more painful for your developers. In the end, it's a lot less work.

Um focus on reusable tooling and components as a nonsense. This is a powerful force multiplier for your migration. So, you know, you can build that into each migration project is i'm going to build a new reusable component that i can leverage in the next one that i can let my teams leverage to build a new service in aws.

Um that's been a really powerful tool. This can be things like modules, infrastructures, code modules, reference architectures, code snippets or scripts or, or even a higher level platform with a team that supports it,

Um adopt pipelines and automation for delivery. So infrastructure of code and automated deployments are the key here. They, they really unlock, you know, a lot of that operational burden that we've we've faced throughout our journey in a move to manage services is key here.

So wherever you can, you know, if, if you're running a sql server database, why not put it on an rds sql server? You know, you don't need to manage patching and backing up a database, move, move to it where possible and then sometimes you're going to have to refactor your applications to do so, but it's worth that upfront work to focus on the core of your business and customer needs.

Um training is key here, obviously, recruiting is hard, you know, it's, it's really hard to go out and compete with everyone looking for, you know, experienced aws talent. So develop a program to upskill your existing staff and and give them training exposure and experiment experience.

Uh it's also important to have a place to play. You know, we, we let developers have sandbox environments where they can figure stuff out without uh much impact.

So the benefits we've seen over our migration, we've seen uh with those applications we've migrated, we've doubled our reliability, pre and post go live.

Um that's really a result of all the things on the left here. So our, our product teams are able now to build and kind of own their own destiny. You know, there's, there's not much friction and they can just go off and build. They're not waiting for a central team and, and we've improved each time, you know, iterate and get better as an onset.

And we've, we've seen that in real life. So, you know, in a highly regulated environment in aws, we're able to adhere to our complex security requirements as a default. We've, we've because of all these things, we've made adhering to these requirements, the easy route and in each migration to aws, we've seen, uh, you know, reduced operational duties.

Uh, there's better reliability, there's less issues for teams to, uh, you know, investigate and remediate with automated pipelines. It's no longer, you know, a team throwing it over the wall and here deploy this for me. You can just use your automated pipeline and then with that lower operational burden, that means more time for you to focus on your real problems.

Yeah. So that's pretty much our presentation here. We have a few minutes for q and a. So if you have any questions, please feel free to ask now or we'll be hanging out here. Thank you, everyone. Thanks everyone.