This technical session focuses on a customer use case and how using the AWS Cloud together with automation has enabled them to standardise and automate their systems.
This talk will describe how this is achieved with two tools, Cloud formation and Puppet. Cloud formation is a declarative templating language that enables the deployment of environments in a standardised way. Combined with a configuration management tool like Puppet allows for the automation of ongoing software deployments and maintenance in a low overhead manner. Puppet is a Configuration Management tool that installs and configures software on instances. Taken together a complete system can be built from the ground up.
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Infrastructure Automation on AWS using a Real-World Customer Example
1. Infrastructure Automation on AWS
Sebastian Krueger – Director of Cloud Engineering
Lindsay Parker – Cloud Architect
Using a Real-World Customer Example
2. Agenda
• Case Study Overview
• Automation Introduction
• Cloudformation
• Puppet
• Demo
5. Case Study Overview
• The challenge
• New deployment of ‘big’ Oracle Enterprise Application and associated
applications
• Tight delivery deadlines
• Only 2.5 technical FTEs
• Greenfields, i.e. no existing H/W, new install
• Multiple environments required – dev, sit, ual, qual, etc
Start with an empty AWS account.
6. Technologies Landscape
• Oracle Enterprise Application Stack
• Oracle Service Bus / SOA Suite
• Mulesoft ESB for System Integration
8. Automation Introduction
• Reproducible
• Consistent across environments
• Build one, run many times
• Template install
• High skilled build, low skilled run
• Automatic resilience and recovery
• Reduce developer turnaround time
9. Cloudformation
• Infrastructure automation and deployment
• Simple to create, update, and delete stacks of infrastructure
• Free! Pay only for the AWS resources created in the stack
• Available in all regions
• Deploy almost all AWS services
• Uses a JSON format
10.
11. Configuration Management Tools
• Configuration Management Tool
• Install packages, template files, and control services on servers
• Tools
• Facter – server information
• Hiera – configuration store
• Share code in modules. Public on Forge, Github.
• Lots of alternatives
12.
13. Demo Time
• Oracle Meter Data Management on AWS
• Based on Oracle WebLogic and Oracle Application Framework used in
various other Oracle Enterprise Applications
Editor's Notes
Good afternoon, my name is Sebastian and I wanted to share with you some of the journey that we’ve gone with some of our AWS customers. Going form a traditional datacentre to an AWS architecture.
We’re going to cover a real-world case study that has been put together using some of the technologies we’ve used in the field over the last 18 months. From what we’ve seen, this may be reflective of some of your environments that you may be looking to shift across to AWS.
Don’t focus too much on the specific technology landscape in this case study and focus on the concepts and principles introduced in this talk and how they might apply to your organisation.
Our cloud journey takes us to the early days of Internet of Things. Sensors connected over the Internet. Specifically, in this case, sending your electricity usage to the metering provider. This could be your electricity meter at your home. Ok, single meter, single stream of half hour reads coming into your data center.
But now we have millions of meters! This is a much harder to solve problem. We have an infrastructure problem and a data torrent problem. Say, a whole new city is being fitted out with these advanced meters. Suddenly you need a whole new set of infrastructure provisioned. Sure, you could buy some new kit. But how long would that take? And at what cost?
This was our challenge. First prove the software was going to work in AWS, then be able to scale up massively very quickly as demand profile requires. Oracle have specialist software to solve the data torrent problem. Specifically, Oracle Meter Data Management. This software has so many features and such a long legacy that it is big and heavy and difficult to install.
Traditionally that wasn’t too big a problem. You probably know from your won experience that these ERP-like applications are installed a set number of times and that number is set in stone. They are effectively sacred, protected behind wall of bureaucracy and governance overhead.
Our story that we are sharing with your today is how we were able to bring agility back into these ERP-like environments.
Our case study will cover the following technology stacks and vendors.
At a high level our architecture looks like this. We have two public network paths, and two private network paths. Inbound public internet traffic is routed through the Proxy, outbound public internet traffic is routed through the NAT. Secured traffic from developers desktops comes in via the OpenVPN tunnel. Secured traffic from our corporate data center is routed via the OpenSwan ipsec tunnel. This allows Mule ESB, Oracle Service Bus, etc to access the on-premise FTP server, or call directly to other backend applications such as JDEdwards that haven’t been moved across to AWS yet.
Remember our Oracle Application. Traditionally it took 2 weeks to get a new install going. And that was if all went smoothly. Each environment is hand crafted. Guess what… you stand up 5 of these hand crafted environments. They are all different! To ensure consistency, we must take out the manual steps. Ensure we have reproducible results, and provisioned at speed.
Initially this is going to be hard, but as you invest in these skills and build up a library of reusable automation artifacts, the results will be groundbreaking.
Cloudformation is awesome! It provides a simple template of your AWS infrastructure. Defined in JSON, you specify your complete network setup, machine image id, security groups, instance type, etc.
Available in all regions. So you can go global in minutes or hours.
At API Talent we use Cloudformation for everything. We recommend a Cloudformation first approach.
Looks like this in its raw format. There are DSLs that simplify this but you loose some of the feature richness of Cloudformation, so at API Talent we like to stay close to the actual JSON code.
So we have our AWS environment defined. But what about our Operating System configuration? Tools like Puppet rule in this space. Take a vanilla OS and apply all configuration based on a textual template.
How to choose which? At API Talent we are Oracle Middleware / Applications specialists so Puppet is great because of the existing Oracle modules.
So we chose Puppet for our Oracle Applications use case. This is due to the extensive publicly available modules that can be reused. But if your technology landscape looks different, you could consider using one of the newer configuration management tools available. But remember to not reinvent the wheel with your automation. If someone has already made a module public, reuse it first.
This is what an example Puppet script could look like. Simple install of a LAMP stack into an already provisioned EC2 instance.
Demo
Oracle Meter Data Managemnet in AWS
- describe the cloudformation template that will kick off the MDM install
- show how to trigger the stack
- talk about what it's doing in the background
- provisioning the aws vpc, subnet, security groups, etc
- cloudformation triggers puppet bootstrap in the EC2 instance and passing in configuration via metadata
- puppet configures OS and installs application
Dialogue between Lindsay and Seb.
Seb: Question 1: How has your experience with CF been so far since you started working with AWS?
Lindsay: - Split into multiple small templates
- Cloudformation generation from ruby templates
Seb: Question 2: How long has it taken you to create the automation for this Oracle Enterprise Application?
Lindsay:
- login to Oracle application