over the next 40 minutes you will hear from two experts in the field of both CMS's and Amazon Web Services speak about best practices in establishing an AWS environment they can manage enterprise-grade CMS before we begin a few housekeeping items regarding the console in front of you zoom offers a few controls that you will see either in the top left-hand corner or at the bottom of your screen audio settings chat QA and raise hand are your controls speaking of QA we hope you pose some questions for our panelists to answer at the end of today's webinar this webinar is recorded and along with a slide deck will be available following the webinar in a follow-up email to all attendees you will be provided a link to both video recording and the deck I'd now like to introduce you today's presenters and panelists BAE Kumar is head of project delivery at prio Sept he is responsible for ensuring the effective delivery of all preset projects including Magnolia implementations prior to joining precept ad they worked at for Accenture as a web and digital consultants joining us from Amazon Web Services is Ruchika a be rich iike is a Solutions Architect at AWS she is also a certified Big Data Solutions Architect focusing on batch real-time and predictive analytics this is Bill Beardsley speaking I'll be moderating today's webinar I am general manager of Magnolia Americas here in Miami Florida and on the right hand side of the screen is Dan Norris Jones a tentacle consultant for prios EFT I'd now like to review today's agenda Ruchika will kickoff webinar discussing business benefits of running your project on AWS then at bay we'll take it over and cover the second part of the webinar addressing the technical implementation and management of running Magnolia on AWS and so with that introduction I hand over the presentation to abate Kumar from present thanks Bill hello everyone just a quick note on precept so we're on AWS consultancy partner and also the leading Magnolia partner in the UK so we've been around since 2004 helping enterprise clients deliver business critical applications put on an emu carry but also in the presence in the US and our core services around content management and cloud infrastructure something very relevant today ecommerce software delivery and web operations so if you need any more information please look us up or feel free to get in touch you know sharing my contact details at the end of this presentation so before we get into the specifics of deploying Magnolia into AWS I just want to hand over now to reach Iike to give them overview amazon's platform thank you Bill this is Ruchika Abby and I have been working with AWS for over 40 years as a Solutions Architect and I have seen a lot of my customers from different verticals deploy Magnolias successfully on our platform so over the course of next few minutes I will go over the benefits they realized before we do that a little bit about AWS so Amazon Web Services is essentially and infrastructure as a service platform commonly referred to as I a s platform that provides a complete set of cloud computing services that enable you to build highly sophisticated scalable for tolerant and performant applications and help you exceed business requirements also to highlight why Amazon Cloud is now a new normal so back in 2013 in a New York summit vulnerable girls and he's recognized as one of the fathers of AWS and he's the CTO and VP of the parent company Amazon he said that you have to stop wasting time and effort for things that do not matter for your customer and one of those things is your infrastructure because it's not a differentiator at that time it was a very disruptive comment and a lot of people couldn't comprehend what he was saying but over the last five years AWS cloud has essentially become a new normal businesses from different verticals have realized that infrastructure is not a differentiator and they have increased our cloud and what I see on a day to day basis is that companies of every size they are now deploying new applications to the cloud by default or they are looking to migrate as many of their existing applications as quickly as they can and essentially for enterprises that the question isn't if anymore it's really just how fast we can move in what are we going to move first so let's see why sorry about that so let's see why AWS can free you up to pursue innovative high value business initiatives by eliminating the time you spend on data center maintenance and operations and this in turn can allow you to put more resources on creating testing releasing your new products and innovate faster to drive your customer value and gain new competitive advantage you would migrate at your own speed leveraging tools and programs and partnerships like precept to help città cloud journey and you can do this while simultaneously improving your security posture and compliance efforts so the first cool principle is to focus on reducing the technical debt and how AWS helps you focus on your core business is first by breaking the cycle of large risky capital purchases and trades you know for for greater flexibility we are operating at our expense it's also referred to as up X versus capex that will eliminate the risk and cost of capacity planning by allowing for you to acquire exactly the capacity you need at any given time and you would pay for only what you are using it would also simplify the complex management tasks that are inherent in keeping a data center filled with ever-changing heterogeneous technology and running it smoothly and lastly the global operations would be a relatively simple matter of replication it's it's important to note I'm trying to obey can you move the slide please I don't know why my mouse stopped working yes thank you so it's important to note how AWS provides enterprises build hybrid flexible architectures we we have built out the broadest and deepest set of hybrid architecture functionality to enable customers to do everything from network security access control powering automated workload migrations and even controlling AWS from on-premises infrastructure management tools if needed and we look into some of those services as we move along but I want to mention AWS VPC or virtual private cloud that helps you provision logically isolated section of AWS cloud in which you would launch your resources and then connect it with your on-premises network using IPSec VPN tunnels or our direct connect private link to enable that hybrid architecture one of the main benefits of AWS is that it enables customers to deploy globally in a matter of minutes and not weeks and months as it would in traditional data centers a bear sorry about that I don't know what's happening so AWS has a concept of a region which is a physical location around the world where we cluster data centers we call each group of logical data centers and availability zone I will refer to that as easy and so will appear going forward we also have a global network of edge locations also called pops or points of presence not shown in this diagram but these are the 102 edge locations from where AWS cloud front which is the content delivery network and route 53 services are offered for deploying Magnolias on AWS you would pick a region which is independent collection of AWS resources in a defined genre fee and you would do that based on user proximity or to meet legal requirements there could be data sovereignty requirements and that's what would help you pick a region within a REIT within each region you have highly redundant clusters of data centers or ACS that are built for fault isolation they are tens of miles apart they have separate power on separate floodplains but they are still connected with low latency high bandwidth fiber network channels that allow customers to build highly available distributed architectures that also has data redundancy so currently we have 53 availability zones 18 regions as you see and four new regions have been announced that will be coming online between now and early 2019 now how does AWS help you focus on building at the core is the heart of our offering let's focus at the bottom of this screen in the stack you will see that core services we offer stuff compute storage and database services we then surround these services and offerings with the range of supporting components like management tools networking services and in the middle of this screen you would see that we have several application augmentation services like that for analytics or enterprise applications mobile services IOT ai the list just goes on all this is hosted within our global data center footprint that I just showed you and that allows you to consume these services without having to build out any facilities or equipments are using a redundant global infrastructure going forward I have grayed out the applications that are not relevant to magnolia on AWS use case but again once you are using our platform you can easily integrate and extend the functionality of your CMS for example add AI capabilities you know so on and so forth but but today we will focus on the core services the blue section that you see at the bottom of the screen has compute which is ec2 Elastic Compute cloud networking and that is VPC virtual private cloud we have load balancers in the compute category we also have some other platform services like Beanstalk and ECS for containers and ABI will talk about those I want to emphasize going forward that if you are migrating Magnolias to AWS if you are running it on prem already like with any other migration initiative every organization will have you know their unique set of constraints and opportunities that would guide that journey to cloud but AWS account team and partners like precept we are there to help you every of the way to go through this iterative migration process we will help you reap lat form your application as needed and go through this closed feedback loop and the phases of your migration it's very important to note and actually all my discussions with my customers this is where I start because security is you know essentially ground zero for us as well as for you it's a moot point exploring new opportunities and initiatives if security and compliance cannot be maintained and for a long time most organizations have had to make a choice between moving fast or staying secure it's a difficult choice and inevitably always security triumphs all one of the fundamental benefits of of AWS cloud is that you are able to do both because security of the infrastructure is handled by AWS and this frees up you to focus on security of your workload and application so you will be able to move fast and stay secure on our platform the AWS infrastructure is custom built for cloud and it has elements designed to inter communicate well and present the smallest attack surface possible and in addition to that we have physical security controls present in our data centers that have been designed to be the most stringent in the world this persuade has led to AWS being trusted by governments military organizations financial institutions including global banks healthcare institutions and other highly sensitive organizations and one of the reasons is that our security team is monitoring the infrastructure all day every day and is well connected with all major security watchdog group and vendors to ensure that potential threats are identified and remediated immediately and we are able to do this because we operate at a massive scale and by looking across more than 1 million active accounts each month running virtually every conceivable type of workload we can see the issues that may occur you know once in a billion operations multiple times a day and that kind of visibility and response isn't achievable with majority of organizations if they are running their you know workloads and managing themselves in a data center the set of security tools that we offer going forward is is incredibly powerful so so you would see it divided by different categories so these tools will help iterate you over different processes of control prevention side of things our monitoring for governance purposes and also remediating and fixing the problems so just protecting is not enough you have to continuously monitor and fix any issues and that's where the dev set cops you know mindset kicks in so it's fully integrated you know as you start using our tool set we have achieved a number of internationally recognised certifications and accreditations that demonstrate compliance with third-party shonan's frameworks so this list is essentially crewing it's it's not an exhaustive list there might be more updates on our websites but you can see that we do cover all of the major compliance accreditations and you can have workloads that our PCI HIPAA compliant FedRAMP compliant workloads and other internationally recognized compliance and regulations are listed here as well one of the great things I want to mention is that AWS customers would inherit all the best practices of AWS policies architecture and operational processes that would help you satisfy your you know security requirements the most important thing is the shared responsibility model for security that we have it's essentially a collaborative approach approach between us AWS and you as a customer so we will help you achieve security in the cloud with the extensive set of tools that I spoke about but then AWS will manage the security of the cloud which is essentially everything below the hypervisor layer and everything above the operating system or hypervisor layer is where you would have to focus your attention on so for running Magnolias on AWS we would partner closely with you for your security objectives and talking about what AWS will manage for you that will be multiple layers of physical and network infrastructure security operational security our data centers that are nondescript facilitator facilities role based access we do the audits we have MFA access systemic change management safe storage decommissioning network protection you don't have to worry about any of that but going up in the stack you as a customer would be managing your operating system network and firewall configuration classifying your data identifying the sensitive data and encrypting it using the tools we provide and again you know monitoring your traffic so I would pass on to up here now to talk about technical aspects of Magnolias AWS and in the end I will be happy to address any AWS specific questions thanks for chica so I now give an overview of the specific considerations for running Magnolia on AWS but it's worth noting that the concepts covered here could equally apply to any other cloud platform so I'm starting here with a fairly complicated diagram so don't worry too much about detail unless of course you're an AWS expert in which case feel free to ask questions at the end but what is it describing is a typical Magnolia implementation within AWS so you can see we're using AWS features such as auto scaling groups for public or delivery web servers which I'll talk about in a bit more detail in the next few slides and you can also see use of AWS security features such as the virtual private cloud VPC which is logically isolated network within the AWS cloud which ricchike mentioned earlier and you can also see different subnets within the VPC used for public servers content authoring servers and the database layer at the bottom there and each of those has different security configurations applied based on their concerns so it's a very scalable and secure Magnolia implementation and it's made possible by use of AWS features you know out of the box so I mentioned auto scaling groups in the previous slide as a quick overview for those of you not familiar an ec2 auto scaling group in AWS is a specification for a set of servers they have three main functions auto scaling which means that AWS will automatically handle the creation and destruction of instances based on load which I'll explain a bit more on the next slide they also provide auto healing capabilities which means terminated or failed instances will automatically be replaced so there are in essence self-healing so for that reason it's best to always use auto scaling groups even for a fixed number of servers such as for the Magnolia or for server even though you don't need that to auto scale you do still do one it's also self hill the other benefit of auto scaling groups is that you can use the so healing nature of instances to configure zero downtime rolling updates so you can kill an instance and have it rebuild itself with the latest code and you can do that sequentially across your public instances and you know ensured zero downtime for your web application so use of auto scaling groups for the Magnolia public and for the author web servers is recommended so to quickly summarize the benefits of auto scaling this diagram shows the old fashioned way of doing things which is still present in my experience in in many organizations the diagram here is showing a set of Magnolia public web servers serving a hypothetical website so you can see here there are eight physical servers in the data center which have been commissioned to be able to cope with the expected maximum peak capacity for this site and so such assume that the maximum load on the site can be handled by these eight web servers so on Monday you can see a capacity of just over three servers and Tuesday just over two and then on Wednesday you can see just over four servers and so on but on every day there is always a fixed capacity of eight servers available so on each day there are always a number of servers idling everything above the line basically so everything above the line here is unused or wasted capacity even when the server's aren't in use you're still paying for this capacity in terms of power consumption and maintenance costs with cloud platforms you can solve that problem by having the infrastructure automatically scale up and down to meet demand you only pay for the time service of running AWS charge for their first hour and then for every minute the infrastructure is running thereafter there is still some slight over capacity as you can see on each day but the amount of the amount spare is considerably smaller than on a fixed set of servers so this is a much more cost-effective approach to running your cloud infrastructure with this in mind there is a particular challenge when deploying an enterprise CMS such as Magnolia to an auto scaling platform such as AWS which I'll explain over the next few slides so let's start by looking at standard CMS architecture and comparing how that differs to Magnolia which is built with scalability and high availability as core considerations so in the model described in this illustration you can see a CMS server which is where you do your content editing this is the author server in the Magnolia world and and delivery servers that are public like publicly accessible and serve publish content for a website or a group of websites so again a public service in the Magnolia world so this is a model that we're familiar with and it works nicely for small to midsize deployments but as you can see there is contention for database operations the delivery servers are making read request at a database at the same time as the content editors are making rewrites requests so a high content editing workload can slow down the website's performance and conversely high website traffic can slow down the content editing experience and there there is also a single point of failure in the database which you can see in a minute or so so really this is a bad application architecture and not one that I certainly recommend or pre-set recommends but it does lend itself nicely to auto scaling because you can spin up a new public web server and it will start serving out the latest content because it's connected to that central database so architectural II this solution is bad for a number of reason number of reasons but it does make auto scaling pretty easy so how does Magnolia differ Magnolia differs in that there is a physical separation between offering and public environments so content is physically pushed from offering to public servers which is actually an export an import/export process with content transferred across HTTP this approach shows all the contentions issues that we saw in the previous slide as Magnolia has separate databases for each environment which you can see the public web servers there so there's one for the offering server and one for each of the public web servers so for an application architecture perspective this is a much cleaner approach but this does pose a problem when deploying to auto-scaling cloud infrastructure so here's the problem as it relates to auto scaling Magnolias instances in this example there was a sudden rush of demand again for this hypothetical website so an advert aired for example or the site got rate shopped or a social media promotion went live and any of these things caused the sudden spike in traffic so this caused public web server free to be created which you can see here in grey at the bottom and the problem is that public web server free doesn't have the latest content on it in fact it doesn't have any content yet so bringing this server into the load now would be you know bad Aidid be serving out a blank site to one third of visitors to your to your platform so so the problem is simple and there is a solution but it isn't completely straightforward as it requires orchestrating events between Magnolia and AWS so here are some of the core services required to set up auto scaling for a Magnolia implementation as mentioned we use ec2 compute instances for running Magnolia public and Orpha servers and these are configured in auto scaling groups and we use RDS for data persistence for the author Magnolia instance which we showed earlier was configured for multi a-z as in multi availability zone redundancy which chica spoke about and we use lambda to make REST API calls into Magnolia to notify the addition or removal of Magnolia infrastructure and we use s free for storage of Magnolia publication keys or the Magnolia publication key is required to authorize activation between the author and public servers and we actually also use it for the the wire file the web application archive file that we used to build ec2 instances which I'll talk about a bit in a minute so here's how we orchestrate events between Magnolia and AWS the objective is to bring public servers into the load only when they have the latest content on them and to do that we basically set up various AWS services to call into Magnolia rest endpoints so at the top here you can see we have a life cycle hook configured on ec2 on the ec2 autoscale group that triggers events when Magnolia ec2 instances are created or terminated by calling lambda be calling lambda function and it does that by SNS which is the simple notification service another service within AWS and then the lambda function then calls into Magnolia to notify that a new instance has been added or removed so if it was added then we used the Magnolia synchronization module to push the latest content to the newly added public instance so on the left of diagram here you can see that there is an auto scaling group health check configuration which is used to check the status as a public server and that's just a standard health check configuration within your supports a scaling group and it calls a custom Magnolia health check API which will return a 200 status ie healthy if the server is running and has the latest content and then the new server can be brought into the load so there are quite a few steps there but we preceptor deployed this process in a robust manner robust manner for a few clients now so we know it works well clearly auto scaling doesn't happen instantly with this approach depending on your content but it can take roughly around 10 to 15 minutes for the process to complete so you need to make sure you configure your auto scaling thresholds accordingly for example you want a scale up at 70 percent capacity for example rather than waiting longer than that so note on ec2 instances these are generated from an Amazon machine image or ami which is a an Amazon virtual machine a preset we we use something called ansible to handle the configuration of software on servers and small being an infrastructure solution and the way we use ansible is we sell the ansible scripts to fetch the magnolia application which is packaged as a wire file from an s3 bucket and then we use the auto scaling group rolling updates to sequentially update each ec2 instance so that ensure zero downtime which is a point I discussed earlier the final consideration for deploying Magnolia to AWS is the public key exchange process so you need a public key to authorize publication from an author to a public instance so what we've set up is that on initial startup of new or for instance a new public key is generated and we then store that in an s3 bucket and then a newly created public instances will then retrieve that key from the s3 bucket when they're when they're created and it'll they'll pull those locally and store them so that's the the core concepts covered there there are a few other things worth mentioning firstly containerization so Magnolia like any other application really can run inside a container using engine such as docker docker is useful if you need to run hundreds of instances on shared infrastructure and also if your solution follows a microservices architecture where there are lots of small service layers and many API endpoints running on different nodes if that does describe your solution and you can use the Amazon Elastic container service or ECS which is a container orchestration service that supports docker containers if you do need to go down that route and at priests precepts we we have deployed Magnolia and docker containers to AWS so if you need any advice on this then feels please feel free to get in touch that's a note on Beanstalk elastic Beanstalk automates infrastructure creation it's useful for smaller Magnolia implementations or for demonstration purposes but we don't recommend it for large scale Magnolia deployments that said Magnolia can work on Beanstalk is it can be single file deployed and can configure a single RDS instance for all the public servers that you need but the orchestration needed to also scale new Magnolia public instances requires a bit of work in terms of creating custom auto scaling lifecycle hooks so Beanstalk only really makes sense if you're not doing auto scaling for Magnolia applications which kind of defeats the purpose of using Beanstalk finally I wanted to mention that for enterprise clients Magnolia provides a set of additional model modules that can help with some of the challenges that we we've described so if you want any more information on these you can speak to your Magnolia partner manager or or feel free to get in touch with Precepts and we're certainly using some of these things on our projects so to summarize Magnolia is inherently cloud friendly platform is architected to work well on any cloud platform including Amazon Web Services it requires some special configurations as described to achieve a fully elastic solution but the benefits as this are a robust and highly scalable Magnolia implementation if you want any more information on any of the topics covered in this presentation then please feel free to get in touch thanks for listening today we will now answer any or at least some of your questions that you might have good thank you Dan and Ruchika I think this next question is for you what are the cost differences of running Magnolia on-premise versus in AWS sure so that would depend on the size of the workload and the size of the content database we have a team that would help compare the cost of total cost of ownership of having Magnolia on Prem and also you know on on our platform but as Dan said earlier there are a variety of instance types to choose from with a different mix of you know resources of for example compute memory networking and depending on which type and which size you put you pick the cost will vary the overall rule of thumb is that it would be cheaper to run Magnolia on AWS because it's scalable infrastructure and you'll be able to scale out say your authors and web servers based on the load or just do scheduled auto scaling for example if you know you have a system that runs that is extensively used or during the day time or during the weekdays but not so much you know during time then you would scale it down using a schedule unicron function or something like that so there are ways to cost optimize your Mongolia deployment on AWS and that's how you would go about you know cost savings exercise after you have deployed and I know it doesn't answer the question but we'll have to take it offline to understand the size implications and then get into the costing exercise fair enough Thank You Russia ger okay another question how are the key secured in the s3 bucket so that's really just a function of the s3 security configuration and also the ec2 instances have something called an instance profile which is the security credentials under which the ec2 instance is running so the best approach there is to set the s3 buckets up so that they can only be accessed by a certain instance profile and then run the ec2 instances in that profile and then the ec2 instances are the only piece of infrastructure that can read those keys great thank you Dan ok that's it for the QA and this concludes the session of our first webinar series first in a series of webinars brought to you by precept and Magnolia thank you very much for attending appreciate your time and as I mentioned early on there will be a follow-up email with a link to the video as well as the opportunity to download the deck thank you very much and enjoy the rest of your morning afternoon or evening as it may be bye bye