 Hey, good morning everyone. My name is Aaron Bear from Athena Health and today I'll be talking about breaking apart the monolith and breaking apart our monolith at Athena Health as well. So the first thing I want to do is give a shout out to my colleague Ryan Walner. Original intention was actually that he was going to be presenting this content to you today. And and much of that comes directly from from his brain, but he was unable to make it and so I Also attending was able to step in for him so Welcome to everybody and hello so myself been building business system applications for 16 years at least I've been working in the public cloud AWS Amazon space for five or more years. I Love writing infrastructure as code That's been my primary focus for those last five years. So You know, I've gone from the old school business applications writing ABAP and SAP and and Coming up through all of that large IT organizations infrastructure to now More recently working in the public cloud. I love to build things. It doesn't matter what it is I really like to build it and So now I'm building things at Athena Health on the infrastructure team there So thanks to Ryan and I'm Aaron. Hello So Often in the healthcare industry Technology sticks around for a long time you know it is Often becomes very old in that time and so It's hard to break into that space with new technologies For example one of the main focus one of the main Functions that Athena Health performs for the healthcare care industry is processing faxes so At Athena Health, we're trying to do a couple of things unbreak health care What we like to say and what that means is we're trying very hard to Bring all of the tedious difficult workflow items of a physician's day or an office administration's day and Free them from that and allow them to just be doctors allow them to just be with their patients and allow them to focus on That information instead of processing like we do for many health care places all over you know, we're processing hundreds of thousands of faxes a day and Not only just things like faxes, but there's still a long paper trail that exists throughout the entire industry so with that though the healthcare industry is trying to go through a Digital transformation moving its information into The digital world instead of in out of filing cabinets and the path to that that Everyone is taking but the health industry or companies like Athena Health are Undergoing is that transformation from the giant monolithic application stack to microservices and a more modern framework for that so that You know We're and in that one of the challenges that we will always face Especially in the EHR market, which is another part of where Athena Health focuses a lot is the adaption of new technologies into the these offices into the doctor's hands into Whatever that may entail So out of Athena Health, we're trying to let doctors be truly doctors not have to spend six hours every day Just doing their paperwork helping to perform efficiencies in that space so computing systems have been moving to cloud-based solutions and more hybrid models for quite a long for not quite a long time, but for for a while and It's hard it is difficult to do that I will say since Ryan developed all this content that slides and content and data and the information that I'm Sharing with you, although I work with on an everyday basis is definitely New for me and presentation layer to you. So as we go through this I'm going to reference notes and And hopefully we'll keep this loose. So in that as well if I'm speaking and I become a little bit unclear in anything We're going to take questions towards the end, but feel free to just Raise your hand and and ask for that clarification at any time so That being said we're moving our products many other companies are trying to move of their products into this space the cloud space the mobile space as operators at the infrastructure level and developers at the application level Moving into a much more flexible CI CD pipeline Making information access easier at the application level and at the end user level and Provide platforms where information sharing becomes much more fluid and much more accessible so another challenged or regular system Thing that happens in our space being health information is that We're often also needing to deploy that infrastructure in the old paradigm into Sometimes the doctor's offices Into our data centers and not as much in the past Into public cloud spaces as we're moving towards today So what we're trying to do is strangle the monolithic design So and I'm here to talk about how We're creating our pathway towards breaking up this monolith and make our transition into the cloud Because as an industry It's important and it's time to be cloud more than it is to have our data locked up in silos and in a Place or location that's difficult to to interact with the data or move that data around or share it in between platforms And as you know health we have you know your typical monolithic design right now it's Apache Pearl and Oracle and it's in one big chunk and All of it is dependent on all of the rest of it and to Expand that you have to lift and shift the entire monolith and What we have found is that it's also difficult to scale that monolith in any And so that You have a stack that can perform to a certain size But the only way to continue to add customers to that or to add functionality to that or or anything is to replicate the entire thing in another place and Certain customers go to this one certain customers go to that one certain customers go to that one So on and so on and so on until you have all of these deployments of this big giant thing that is Very Inflexible you're bound by that monolith to what data you can view what data you can Use what data you can see for instance in the health care industry a big trend is for merging large hospital groups into larger hospital groups and if Say hypothetically a one customer was already Athena health Merged into a hospital group. There's also Athena health But they were already on two different Athena health systems There's a very big challenge for us to bring those together in a useful way And so why micro micro services in that paradigm is because that scale there's There's no way to do that in the current monolithic platform the other is That you know you're bound by that technology stack for any innovation that you can make into the market and so microservices and our path towards microservices is a Way for us to be able to innovate faster so that someone can have an idea and write a service for that and tie into our data stack and have You know something up and running within days where before You know it may take Quarters to get a release into the pearl code where one Change might affect the entire The entire application stack in itself so also in that as a large organization That Is at the head of this Model in the health care industry Having that big monolithic stack makes it hard for us as an organization to continue to hire new talent that wants to come in and Do something really exciting right because we can say oh you're really smart. You've got 10 years or 20 years of writing applications, and you're building all these things Come work for us, and you can write pearl and query data out of Oracle with SQL. I mean that's not too thrilling so our journey towards this Microservice and Mesosphere environment is to allow us to be more agnostic Agnostic to what technology someone has to use to make something a part of Athena health software offers across the board So the challenge is then breaking apart that monolith right so You know you've got this big thing and what we're trying to do is to get to all these yummy little pizzas all over the place That we can eat and consume at any time we want to and the middle ground is Breaking that apart in chunks right everybody loves pizza everybody everybody wants to have a slice everybody wants to do to make it Easier to Adapt into the overall platform So the one thing that is challenging, but also very important is to avoid the distributed monolith, right? We can't just lift and shift this pizza all over the place We can't just take this big stack and Containerize the big stack so that we can just launch this giant stack more times in a container You you don't get any benefit out of that you end up paying for You end up paying a lot more Especially in the cloud space for no actual platform benefit as You move towards this the benefits you gain is is you get a polyglot environment, right? You can think up of an idea write it in whatever thing you want and hopefully you're going to get the data that you need to make your application Work and do Really awesome things But you're not going to want to be bound by that monolith to do that And so we are using the strangler pattern to do that so Choose to keep this big monolith around we don't have too much of a choice to just get rid of it in one file swoop but what We feel like we can do well is Move towards the microservice architecture over time moving from the old to Platform 2.0, which is what we might call that at Athena health and and and know that We can rely on what we have and we can break off chunks and Start net new information and products in this new Model by just kind of squeezing pieces out of that monolith over time so You know the reason why we choose to do that is That One it makes it easier to write in that new functionality, right? With the monolith you're bound by all the interdependencies of what that monolith represents You're bound by you have to write in pearl you have to know that you know Not only is that host accepting the incoming queries for any requests to your application stack but it's also You know running the database and that data is only one thing. It's a relational database. You can do a lot of stuff with SQL but Can you really do a lot of good stuff with your data in SQL or use it in different ways or move it into different patterns that you are able to Support these new and Exciting models that hopefully you're you're coming up with in your head and hoping to become some part of the framework that we Want to provide to help the industry improve its efficiencies so You know another thing that this helps you do is move more quickly into a pattern where you can Break things and fix them more quickly you can You know testing the monolith is really hard but testing a component of that monolith That I wouldn't even that's not actually correct So you're not going to be on the test a component of the monolith in this model but testing that new functionality outside of the monolith in this model becomes a lot more easy and You know scaling that monolith with your business is really challenging It's definitely a big challenge that if you know health follows finds in that You know the only way we can scale is to repeat this giant thing Spoke to this just a bit but you know in the monolith You have your you know your classic three-tier web application You've got this big giant database that holds all of your data You have some component of your application stack that accesses that data You have a layer that's doing your business logic to that information And then you present that to the user in some way as a whole so our solution and and what we're working towards is Breaking that apart and a really important part of that journey for us has been POC evaluations of lots and lots of technologies Trying them out just figuring out, you know, what works and what doesn't in a Short cycle Environment and part of this as an organization Athena health has made a big change over the past year moving to an agile Method as a company so not just in our DevOps teams not just in our operations and not just in in As a department what we call I AAS But at the developer level and at the application developer level Reorganizing ourselves into scrum teams. So we have smaller groups of people working on more focused points of the product and iterating on those projects much more quickly So in doing that we can function and we can perform these POCs more quickly The information that we learn out of those Can be shared amongst our groups more quickly and as we find useful things out of that We can start putting them in place, you know, one of our mandates or or needs in the past year has been moving from Only our data center. So this is going to represent Athena health and it's on-premise data center and all the components of what that is to the public cloud space First being, you know, Amazon, but we're already working in Azure. We expect to try to be agnostic in the platform the Place where with we run applications But build an environment and an ecosystem that is consistent across all of those at the same time These are a number of the components that we've chosen so far that we're working towards right now DCOS, MISOS, Portworx, Docker Docker Docker, Amazon Web Services, which is the team that I work on in our group Mostly Ryan is our is a counter to me in our on-prem kind of activities and deployments of this so that we are Moving to An overall solution that that fits the microservice platform really well So our future state as we are transitioning from that monolith Moving away from a single code base Into a much more flexible Write what you want use what technology you might need Environment allowing you to refactor and rewrite little components of your overall architecture stack much more quickly You know if right now if there's any Component of our monolith that that we want to change It's likely that it's really difficult to do that because of the interdependencies of everything else in that application stack in this microservice model, you know your goal is to Remove that dependency from the rest of your infrastructure. So the component of that that your deploying You can pull it out it can go away and or and it can be replaced without the entire Deployment need to be updated at one point all of your patches to just go cleanly into the system on your Your second release of a quarter where if that doesn't happen, you know, you've got a systemic system-wide issue in This smaller model you have the ability to Fail fast and fail forward you can release small alpha products into this environment To try them out it won't matter to the rest of your Your stack because you can launch it Try a subset of people to it pull it out next release release and beta move it out into production much more quickly Once you do that then you can go back to your monolith and start pulling out bigger chunks of that monolith and Moving components of that into your new infrastructure more efficiently and more successfully so Another key part of what we feel is important and what seems to be a really my opinion smart idea is that You make sure that your infrastructure is also API driven That there is a level of abstraction from where you're running something That your application developer doesn't need to worry as much about so You know that that API abstraction is key A value that you can provide in that abstraction is that you can move your individual business context outside of the platform with which you're running your containers or running your services Into that API level so that You're not Bounds by having to know every single thing about what you need to run your application and you can just run your application API driven deployment can speed up your feedback loops from What you think is happening what you think should be happening and That that loop back is important for Moving more quickly with your deployments your application development and your overall performance as a system so So a large part of also moving to this model is As an organization following it at the organization level To an agile transformation Like the infrastructure itself is making a transition to and then you're hoping to push ownership of these services into the teams that are developing them and You're not having to deal with Services that you may or may not know anything about at an operations level or at the IT level and allow The application team to deploy to the API know that their system should be up and running Know that when they fail they might be able to make their own update their own iteration on that and and manage how their service is working independent of the platform that it's running on another very important functionality that this is providing for us is the ability to run our underlying opera in from our underlying Technology stack that these applications are running on anywhere. We want to and our API in front helps to orchestrate the need the place where that Container service may run for example this represents two different things It represents exactly the same thing in two different places. So DC us and Miso's running in AWS DCs and Miso's running on-premise bare metal in the class are Front-end endpoint into what is on-premise can reuse The enterprise class net scalers that we already know as an organization and already utilize throughout our on-premise infrastructure and an ELB in front of how we get into our stack within on But the abstraction layer allows you to post your payload to the overall system and make a choice as to where you want to put it or Via business logic within the API itself help you choose the best place to run this In that, you know, you might need access to data that can't live in the cloud in the healthcare industry possibly and so you need to run on-premise, but You can rely on platform in both places is exactly the same You know Miso's fear says operating system everywhere operating system in the cloud this Is the the the place where we are and where we're more moving to So a big thing in the model if the big thing on our challenge is silos of information Giant Oracle databases that contain all of this important information But there's no way there's no easy way to work with it in any model outside of SQL queries in Oracle and the way you get You know information out of that relational database, you know, you can hire all of the super super talented SQL Jedi's you can but you still only have that data in our case not only in one place, but only in one place a bunch of times and You know when you have your data like that it is possible to affect Other places where that data other places where you need to get that data in negative ways it makes it hard and so You know a goal of our data layer is to extract that out of those silos and Give the application developers their choice of where they need their data and how they need it and Write their applications to more effectively use sources so they can expand it out put it all back together tie it together and and then Bring it back into the data silo right now bring it back into the monolith for its overall storage an interaction with our product as a whole or You know expose it out of some new service that That enhances our overall offerings to our customers Internally one of the ways that we do that is I Guess I learned this morning the smack stack but components of that smack stack Where we can stream data out of Oracle from on-premise and move it into the cloud and transform it in ways that make it much more useful and Then services then can be deployed to use the data in that manner instead of having to call Back onto on-prem select the data out of the big data silo Figure out what to do with it the data is coming streaming in it's being processed and transformed and it can be put back to where it needs to be to Enhance the overall You know data records of patients in a doctor's office or or something along those lines You give the application developer the ability to choose the right place to put its data or the right way to use its data Instead of limiting them to this this one way or no way Methodology so Just taking a quick look here And this song I just kind of describe one of the ways that we might be able to do this again We have our big silo of information And we can take that data out do processing and spark There's a layer this source agnostic CDC For example one way that we're transforming data out and distributing them amongst doesn't matter what what where the data is going necessarily could be on-premise could be in the cloud Pulling the data out with Kafka streaming it using Kafka mirror maker to distribute it very quickly to our other locations of our platform using spark to do Interesting data transformation or processing information on that storing it back into new data stores within the platform itself it might go from Oracle to Kafka to elastic search to spark back to elastic search to Neo4j and You Get that data out of the silo in a really efficient way And then you can distribute it across your platform which your platform might be distributed across many different locations So with that there is a little bit of a demo here and What we will see is our Business logic API endpoints into these two platforms Where the application developer can Define their marathon task In a way where they can either choose the destination and they want their application to be deployed to And and or multiple locations and have a single API interaction, but be able to Interact with all of our multiple platform locations to perform that and I'll just let it play Hopefully we can glean from this What is happening? And if and if we do end up with questions, I definitely can kind of answer this But basically it starts out with a API post asking for what are my environments available and that it returns that I have this Available in a playground. I have it in Bedford, which is one of our data centers And I also have a dev environment which would be located in AWS. I can define my job and in that marathon task I can Give these Clues to where I want my job to run how I want to run it what's happening when I run it This hopefully is going to be posted and We have a success it is created I can go back to my API and Ask the environment for The status of What I have running Fonts really small on my side too, so we're getting to basically what we're doing is interacting with launching a service in Two different locations with a similar With the same Definition of the task we get information back we know that how many instances are running in both environments and We're seeing that we're in two different environments This is the same API interaction for the same service running in two different locations and and What we'll also be able to see is that we can post the API to manage the the scale of that and In the end We have one place where a Developer can interact with many systems across the Environment so Planning is definitely a key to this just Moving the monolith to somewhere else isn't necessarily the answer Making Lots of POCs to experiment with technologies is really important Some other challenges service discovery and load balancing is always going to be hard Start small start with Small components of your application stack that you may Have or or not and then once you are starting to get the handle of that your organization has made that transition into this new model of Deploying services and creating services and then you can come back to your monolith and start pulling chunks out of it in a much more effective and much more easy way and You know the other thing that is difficult that you want to talk about sooner than later is is you know ownership of who's who's on call for what and You know instead of just typically throwing it over the wall to operations This Plan might help you better serve that and help to break apart your monolith so With that If there are any questions, I'm Aaron at Salinas on Twitter and Does anyone have any questions? You mentioned moving applications and you also talked about the whole idea of streaming data out using spark and stuff It's cool. It's you know a materialized view and like Writing applications for like new stuff, but it doesn't really address that one of the original Problems that you talked about in the very beginning, which is the user sharding User sharding deploying new instances of Oracle to be able to handle more users because you can't grow Oracle in play and then another issue is that all that data that's been streamed out is only it's read only in general You're not going to be able to stream it backwards back into Oracle and figure out which shard to go to and that kind of stuff Or can you I don't know that's what I'm asking I hope you have a similar problem because we also that user is so fundamental We can't just break out the users into some users service because it's too Fundamental to the the monolith right but from the monolith you might be able to break out the authentication component Or you might be able to break out a smaller component over time and pull that out and just like the streaming Wouldn't be done processing the the processing would be done bark Times the streaming in our case is being done using Kafka and out of that and and in that as well Hopefully and in our case There can be an API in front back into the original data source And so you can stream the data out Process the data Transform it into an answer for what you want and then post it to an API That then gets consumed back into your original data source. That's also rewrite bit about the sharding though any ideas and how Your company's gonna help shard So with my knowledge base I can't actually answer that question as far as the overall structure of how they want to consume data back into the whole of Athena net but You know, that's a good question. It's probably answered many different ways, of course But I don't think that streaming data out of a data source Necessarily means that you can't put data back into that same data source after it's been processed in some way The key I think the takeaway would be try to make it as an API Where you can post back to some location and then that that service or that logic is able to determine the proper place to store Again, thank you. Yep. All right. Well, thank you very much