Tech huddle paas_session

1. DevelopingonCloud Rob Edwards – Consulting Systems Engineer,Cloud &Data Centre Software @clijockey
2. Satya Nadella - Microsoft “Every Business will be a Software Business”
3. Speed of Applications Delivery is Critical
4. Building Applications BUY Commercial Off-the- Shelf Software (COTS) BUILD Traditional Architectures/Methods BUILD Modernise: “Cloud Ready” BUILD Cloud Native / Microservice Mostly Hidden / Irrelevant Our developers in our environment(s) (inc. contracted developers / ISVs) Integrated Infrastructure Cisco Validated Design, Blueprints, I&O Automation Integrated Infrastructure Automation, Orchestration, Self Service Integrated Infrastructure / Commodity / Programmable Infrastructure-as-a-Service Runtime Environments Application Framework / Programming Environment Integrated Infrastructure / Commodity / Programmable Infrastructure-as-a-Service Runtime Environments Application Framework / Programming Environment PLATFORM-as-a-SERVICE PLATFORM-as-a-SERVICE / Container STACK
5. Building Applications Mostly Hidden / Irrelevant Our developers in our environment(s) (inc. contracted developers / ISVs) Integrated Infrastructure Cisco Validated Design, Blueprints, I&O Automation Integrated Infrastructure Automation, Orchestration, Self Service Integrated Infrastructure / Commodity / Programmable Infrastructure-as-a-Service Runtime Environments Application Framework / Programming Environment Integrated Infrastructure / Commodity / Programmable Infrastructure-as-a-Service Runtime Environments Application Framework / Programming Environment PLATFORM-as-a-SERVICE PLATFORM-as-a-SERVICE / Container STACK Cloud Management Cloud Native App Development Platform Container Deployment and Automaton BUY Commercial Off-the- Shelf Software (COTS) BUILD Traditional Architectures/Methods BUILD Modernise: “Cloud Ready” BUILD Cloud Native / Microservice
6. Virtual Machines vs. Containers Server 1 HYPERVISOR GUEST OS BINS/LIBS APP 1 GUEST OS BINS/LIBS APP 2 VM1 VM2 Server 2 HOST OS BINS/LIBS APP 1 BINS/LIBS APP 2 CONTAINER ENGINE C1 C2 Runs Application on Virtual OS Decouple Application from Infra Environmental Consistency Density Boots in msec/sec Runs OS on Virtual Hardware Full OS in each VM Boots in sec/mins Dockerfile FROM unbuntu:14.04 RUN apt-get install –y-redis-server EXPOSE 6379 ENTRYPOINT [“usr/bin/redis-server”]
7. Virtual Machines Server 1 HYPERVISOR GUEST OS BINS/LIBS APP 1 GUEST OS BINS/LIBS APP 2 Server 2 HYPERVISOR GUEST OS BINS/LIBS APP 3 GUEST OS BINS/LIBS APP 4 VM1 VM2 VM3 VM4
8. Virtual Machines Server 1 HYPERVISOR GUEST OS BINS/LIBS APP 1 GUEST OS BINS/LIBS APP 2 Server 2 HYPERVISOR GUEST OS BINS/LIBS APP 3 GUEST OS BINS/LIBS APP 4 Server 3 HYPERVISOR GUEST OS BINS/LIBS APP 5 Shared Storage
9. Containers Immutable and Ephemeral Server 1 HOST OS BINS/LIBS APP 1 BINS/LIBS APP 2 Server 2 HOST OS BINS/LIBS APP 3 BINS/LIBS APP 4 Server 3 HOST OS Shared Storage CONTAINER ENGINE CONTAINER ENGINE CONTAINER ENGINE C1 C2 C3 C4 $ docker run -p 5000:5000 simple_flask:dockerfile python hello.py C5
10. Containers Immutable and Ephemeral Server 1 HOST OS BINS/LIBS APP 1 BINS/LIBS APP 2 Server 2 HOST OS BINS/LIBS APP 3 BINS/LIBS APP 4 Server 3 HOST OS Shared Storage CONTAINER ENGINE CONTAINER ENGINE CONTAINER ENGINE C1 C2 C3 C4 C5 C6
11. Containers Immutable and Ephemeral Server 1 HOST OS BINS/LIBS APP 1 BINS/LIBS APP 2 Server 2 HOST OS BINS/LIBS APP 3 BINS/LIBS APP 4 Server 3 HOST OS Shared Storage CONTAINER ENGINE CONTAINER ENGINE CONTAINER ENGINE C1 C2 C3 C4 C6 $ docker run -p 5000:5000 simple_flask:dockerfile python hello.py
12. Traditional Servers Describing the New World Cloud Infrastructure Containers Transient Containers Containers at Scale http://searchservervirtualization.techtarget.com/feature/Application-containers-continue-data-center-invasionhttp://www.cloudcomputingexpo.com/node/3293710
13. Why “Cloudify “Apps BUILD Modernise: “Cloud Ready” BUILD Cloud Native / Microservice BUY Commercial Off-the- Shelf Software (COTS) BUILD Traditional Architectures/Methods Source: Forester June 2015 20% “Elastic” Apps redeploy Apps “as-is” 70% Lift and Shift Apps refactoring
14. Modernise: ‘Cloud-ready’ Re-architect + re-package? Application Framework Runtime Platform Infrastructure Automation Infrastructure Dev IT Ops IT Ops IT Ops
15. Source: Forester June 2015
16. BUILD Cloud Native / Microservice Cloud Native & Microservices BUILD Modernise: “Cloud Ready” BUY Commercial Off-the- Shelf Software (COTS) BUILD Traditional Architectures/Methods DevOps Shared responsibility Common incentives, tools, process and culture CI/CD Release early and often Higher Quality of Code Microservices Loosely coupled components Automated deploy without waiting on individual components CLOUDNATIVE
17. Platform-as-a-Service - Common Functions Programming Environment (Native or IDE Plugin) Service Brokering – Shared Routing Tier Managed File Transfer and Artifact Distribution Dynamic Provisioning - Placement Register message queuing Fault Tolerance and Automated Recovery Dynamic Provisioning - Scaling Dynamic Provisioning – HA Logging Metering Health - Performance Monitoring Authentication and End User Onboarding Dynamic Provisioning – ‘Sharding’ Data Externalisation – Bind Apps with Data Services Automate Load Balancing and DNS Runtime Sandboxes and Isolation Workflow Engine Deployment Templates Map session state to distributed cache IaaS Integration
18. The Perfect Dev Experience? $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ $code$ Production (or Testing area)My Branch My Branch My Branch Make sure I/we haven’t messed up. If OK, put it out there & keep it working. Performance Information DEV
20. Containers at Scale Infrastructure-as-a-Service ZOOKEEPER Service CONSUL Agent MESOS Secondary ZOOKEEPER Service CONSUL Agent MESOS Secondary ZOOKEEPER Service MARATHON Leader MARATHON Secondary MARATHON Secondary CONSUL Agent CONSUL Agent CONSUL Agent CONTROL VM LINUX DOCKER CONTROL VM LINUX DOCKER CONTROL VM LINUX DOCKER WORKER VM LINUX DOCKER WORKER VM LINUX DOCKER WORKER VM LINUX DOCKER MESOS Master MESOS Master MESOS Master MESOS Master CONSUL Agent DNSMASQ LOGSTASH DNSMASQ LOGSTASH DNSMASQ LOGSTASH DNSMASQ LOGSTASH DNSMASQ LOGSTASH DNSMASQ LOGSTASH
21. Containers at Scale Infrastructure-as-a-Service ZOOKEEPER Service CONSUL Agent MESOS Secondary ZOOKEEPER Service CONSUL Agent MESOS Secondary ZOOKEEPER Service MARATHON Leader MARATHON Secondary MARATHON Secondary CONSUL Agent CONSUL Agent CONSUL Agent CONTROL VM LINUX DOCKER CONTROL VM LINUX DOCKER CONTROL VM LINUX DOCKER WORKER VM LINUX DOCKER WORKER VM LINUX DOCKER WORKER VM LINUX DOCKER MESOS Master MESOS Master MESOS Master MESOS Master CONSUL Agent DNSMASQ LOGSTASH DNSMASQ LOGSTASH DNSMASQ LOGSTASH DNSMASQ LOGSTASH DNSMASQ LOGSTASH DNSMASQ LOGSTASH CONTROL NODE 1 CONTROL NODE 2 CONTROL NODE 3 WORKER NODE 3 WORKER NODE 1 WORKER NODE 2
22. Containers at Scale Infrastructure-as-a-Service ZOOKEEPER Service CONSUL Agent MESOS Secondary ZOOKEEPER Service CONSUL Agent MESOS Secondary ZOOKEEPER Service MARATHON Leader MARATHON Secondary MARATHON Secondary CONSUL Agent CONSUL Agent CONSUL Agent CONTROL VM LINUX DOCKER CONTROL VM LINUX DOCKER CONTROL VM LINUX DOCKER WORKER VM LINUX DOCKER WORKER VM LINUX DOCKER WORKER VM LINUX DOCKER MESOS Master MESOS Master MESOS Master MESOS Master CONSUL Agent DNSMASQ LOGSTASH DNSMASQ LOGSTASH DNSMASQ LOGSTASH DNSMASQ LOGSTASH DNSMASQ LOGSTASH DNSMASQ LOGSTASH CONTROL NODE 1 CONTROL NODE 2 CONTROL NODE 3 WORKER NODE 3 WORKER NODE 1 WORKER NODE 2 What about: • Initial host deployment and registry? • External-to-[new] services comms and records? • Service-to-Service comms? • Log collection, forwarding, and analysis? • Storage for ‘statefulness’? • Virtual networking? • Task scheduling? • API management?
23. • ALL THE COMPONENTS FOR YOUR MICROSERVICES PLATFORM • OPEN SOURCE • CLOUD AGNOSTIC.
24. PaaS vs. Container Stacks The lines are blurring Programming Environment (Native or IDE Plugin) Service Brokering – Shared Routing Tier Managed File Transfer and Artifact Distribution Dynamic Provisioning - Placement Register message queuing Fault Tolerance and Automated Recovery Dynamic Provisioning - Scaling Dynamic Provisioning – HA Logging Metering Health - Performance Monitoring Authentication and End User Onboarding Dynamic Provisioning – ‘Sharding’ Data Externalisation – Bind Apps with Data Services Automate Load Balancing and DNS Runtime Sandboxes and Isolation Workflow Engine Deployment Templates Map session state to distributed cache IaaS Integration
26. • Platform for cloud native development. • Developer/Operations friendly. • Easy-to-adopt, easy-to-use. • Builds a ‘Developer-Experience / PaaS layer’ on top of our Mantl • An end to end, integrated stack for running container workloads. Including Deployment automation & assurance • Designed to grow into a platform for application and data services.
27. SHARED STORAGE: (EMC, NetApp, IBM, HDS, Nimble…) CONFIGURATION MANAGEMENT: Puppet, Chef, Ansible BUY Commercial Off-the- Shelf Software (COTS) BUILD Traditional Architectures/Methods BUILD Modernise: “Cloud Ready” BUILD Cloud Native / Microservice METAPOD Enterprise Cloud Suite / UCSD APPLICATION CENTRIC INFRASTRUCTURE (ACI) UNIFIED COMPUTE SYSTEM (UCS)
28. More Information MANTL: mantl.io Shipped: ciscoshipped.io Microservices: martinfowler. com/articles/microservices.html Applications & Microservices with Docker & Containers - thenewstack.io DevOps: The Project Phoenix book More Information

Editor's Notes

Today talked about IaaS and how it enables
easier consumption of infrastructure resources
Flexibility and more on-demand characteristics

Build, Ship, Run

Not sure what panto character I am!!!

Sure wont answer all your question today but the idea is to make you aware of things that Cisco are doing that you might not be aware off.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

speed up delivery and deployment of applications. The current process is time consuming and has many processes that are manual and laborious. For example – currently it is time consuming for application owners to get application single sign on for external facing applications
The IT team is looking to drive higher value service offerings to the business and provide these services at the greatest cost/value ratio as possible where auditing and asset protection is critical
Key Value Themes:
Create Services that allow for more agility and innovation which align to security / auditing and operating
Faster SDLC
Time to market
Limiting project resource-management bottlenecks
Authorisation services
Know Me project – build applications that leverage the understanding of your clients
Reduce cost of IT Services
Higher Data Centre utilisation
Hybrid Cloud
Reduce management costs of application portfolio
Provide world class IT services to the BUs and drive innovation
Leverage current investments and work with existing and new applications

This ‘win-win’ helps by:
Removing all friction of consuming IT from the developer, incentivising them to align with consuming IT in a compliant way
Reducing the prevalence of “shadow IT” by offering IT in the way a developer might consume in public cloud
Enabling IT to be a broker to the public cloud by leveraging hybrid capabilities
Ensuring architecture and maintenance consistency across the application portfolio
Providing a standardised architecture and runtime pattern which exposes developer services and APIs which can reduce development times and create more value in the SDLC
Understanding the IT as a Service theme is important in connecting with the higher order strategic benefits of Apprenda
All about the apps!!

Today talked about IaaS and how it enables
easier consumption of infrastructure resources
Flexibility and more on-demand characteristics

Build, Ship, Run
COTS
Based on validated & reference designs
Relationship between development and ops is an instructions document
Detailed instructions on getting it deployed (type of servers, virtual appliances etc.)
HA/resliliance comes from the infrastructure and always up and running

TRADITIONAL
Apps developed in house
developers hand off to operations
operations support with closer links to devs
Adopted more automation (ECS, config mgmt tools, CliQr)
close links to infra and app mgt.
Start to publisise services
transactional relationship
Self service portals being the handover point between teams

MODERNISE
Move to providing consistent, repeatable environment
Closer work with operations and development teams
PaaS sit on top of it
More abstraction of the underlying resources

CLOUD NATIVE
Evolution of PaaS
Even closer relationships with teams and emergence of container stacks
Removes the friction of consuming IT/infra for the developer
Enable better hybrid cloud capabilities
Start to offer public cloud like services locally

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

The aim of this slide is to account for the Top 10 dev languages – what’s popular, what’s universally used vs. used in one type of approach, what’s ‘new vs. old’, when it comes to PaaS, what do the language frameworks imply a focus on from a Dev/software architecture pov.

Notes.
Python, JS, Perl, Ruby = scripting languages in the main
Ruby onRails  A web framework written in the Ruby
Node.js  JavaScript runtime built on Chrome's V8 JavaScript engine.

COTS often = Client-Server Monolith (1 instance-to-many in same tenant) – 3-tier? - Windows or Linux
Traditional often = Client-Server Monolith with Waterfall dev/deployments and clear line between Dev and Ops – 3-tier? – Windows or Linux
Modernise often = Move towards DevOps, Move towards CI/CD/Agile, Add SaaS front-end, Rebuild elements of the App, Add Service APs, Add service message queue capability for distribution, look at different storage techniques, add support for ephemeral/immutable instances, etc. – More Linux, Windows if in a Windows PaaS (Azure, Apprenda)
Cloud-native = Agile/DevOps, CI/CD, Microservices architecture built using languages that are shown (Go, Scala, etc. rising), Separate data, business logic and user interfaces, true IaaS and Infrastructure Programmability, possibly PaaS but likely Container Stack, etc. - Mostly Linux today but MS filling the gap

The choice of languages reflect the above

COTS  Client software is main concern. Looking for a HA foundation with validated designs for applications. Cater for Test/Prod.
Traditional  Similar to COTS but efforts around the Ops to Dev ‘interface’ offer value. Traditional integrated infrastructure + tooling (UCS Director/ECS, vRealize, HP, etc.)
Modernise + Cloud-native  Different territory and lots of value from PaaS + [purple box]. PaaS doesn’t offer much in Build-Traditional but often talked about in that area (in a move to PaaS as-is?) capacity…

PaaS
Programming Environment inc. Dev tools
Runtime Environment
Runtime (DB, Web, etc.), middleware, and OS
Dynamic provisioning
Virtual, BM, and Container machine management
Artifact distribution
Load balancing
Fault tolerance
Messaging bus
System monitoring
Logging
Metering
Identity
“PaaS solutions provide support for both the development and deployment of software application in the cloud.”
“While one-to-one mappings of software from on-premise to cloud platforms are possible, statelessness and data externalisation from stateful sessions and applications emerge as solutions if cloud benefits such as elasticity and performance are aimed at.”
“PaaS Migration is the process of moving from the use of one software operating and deployment environment to another environment, e.g. from an on-premise solution to the cloud”
“Statelessness is a requirement for VMs and applications to be deployable without data.
As a consequence, data externalisation is required to prepare for scale-out, which necessitates externalisation for an efficient management”
of elasticity requirements.“Customers do not manage their virtual machines, but are concerned with middleware components, their development and deployment. They develop and deploy applications within an existing API or programing language. PaaS Migration is the process of moving from the use of one software development and deployment environment to another environment.”
“Two classical software architecture concerns need to be embraced by a PaaS architecture migration process solution:
architecture re-engineering, i.e. the adaptation and modification of a software solution to meet the requirements of elastic and resilient cloud provisioning,
architecture ageing, i.e. the validation and correction of programming and data aspects aiming at incorrect and outdated structures.
Migration Techniques:
Direct deployment to PaaS with limited changes (either the entire application or part of it)
Immediate pay-per-usage and flexibility from provider pov (no good for Enterprise?)
Deployment on PaaS with some level of architectural and/or design transformation
Programming Models for Stateless Programming  elasticity (scale out, run anywhere) and scalability gains
Databases for State Management  elasticity and scalability gains
Data Externalisation for Resiliency  resiliency gains
In case of PaaS, the consumer controls software deployment and configuration settings whereas the provider provides the application runtime environment, development life cycle support tools and other services that are required to host the consumer's application.
PaaS: limited interoperability and lack of common terminology

Fallacies +
Co-location of the application layers and components
Resilience, low latency, and high bandwidth connectivity between layers
Applications disposition for vertical scaling, considering the underutilized infrastructure in traditional
data centers
Performance optimization approach, based on application deployment platform tuning, that relies on fine-grained control over the deployment platform
Use of multiple technologies and frameworks, many of which may be non-standard
Dependence on enterprise level shared services related to security, directory services, data management and so on
Complex application integration scenarios with reliance on multiple architectural patterns
Application design patterns (for example, sticky session, synchronous v/s asynchronous communication)
Architectural patterns needing heavy data traffic within the WAN
PaaS provider should support technologies such as the enterprise service bus, message oriented middleware, managed file transfer
What we have with virtual machines today;
VM separate the operating systems from the underlying hardware it runs on
if you want multiple applications you will have multiple virtual machines
each VM has a full operating system
application deployed on top of the OS and the required libraries and binary's installed
can be big and hinders portability
Hypervisor level isolations an also an OS per application
Benefit is you can run multiple operating systems on the same hypervisor
Also overhead of multiple servers
Boots in minutes

If you compare and contrast to containers (very fast paced technology) – really 2013/2014 made appearance with Docker
Separates applications from the underlying operating system that it runs on
extremely fast and portable for applications
concept been around for a long time
uses features in the Linux Kernal (CGroups, namespaces, network space)
Docker made it easy and popular when came around around 2 years ago
have a single operating systems
applications are isolated within the OS
user container object
each container is isolated from each other (similar to logical partitions)
minimise the overhead of having multiple OS
makes applications portable
can develop on laptop and then move to infrastructure easliy (it’s actually the same container)
all it needs to run is in the container
removes dependency hell
benefits
scalability (really small)
portable
density (can put more on machines)
drastically reduces the development lifecycle
no longer tided to the env under the app
really enabling mincroservices
Based on the time it takes to get a VM up and running with the correct libraries and applications installed (even with automation) we look to keep them up and running as much as possible by building in HA capabilities into the infrastructure.

If upgrades are needed then the existing VM would be fed and waters and an upgrade process followed.
Should a problem occur in the infrastructure mechanisms are in place to migrate the workload to another part of the infrastructure.

This is usually transparent to the application and the application doesn't’t actually give any thoughts to to HA.

This has been challenging with public cloud providers in that parts of the infrastructure can disapear with little or no notice and it may not automatically move instances around.

As a result application developers started to add logic into the application and its management so that should something happen it would would take care of HA rather than relying on the infrastructure.

For scale will make VM bigger rather than depoying a new server
Now if we look at the way we work with containers a different approach is taken. If we use the same scenario of wanting to upgrade an application to support a new feature rather than creating a release window and working out how to upgrade the application we just deploy new tested container to replace the old one and destroy the old one.

Thing of the value of this sort of thing when it comes to testing code, you can very quickly test features as you go and destroy the test environment rather than spending all your time manipulating VMs or spinning up new VM for testing purposes.

For scale just deploy a new container and add to the service
This new world has been described in a number of different ways on the Internet and by the pionears of DevOps

http://www.cloudcomputingexpo.com/node/3293710

http://searchservervirtualization.techtarget.com/feature/Application-containers-continue-data-center-invasion
Cant just take a VM and put in the cloud
need to make app cloud ready
Why? (story for each)
Elasticity/scalability
Location independence
Best location at a given time
Speed and time to market of a service
Application accessibility
Flexibility
Pay for what you use

Considerations
Latency – often more variable latency
Noisy neighbors
Applications can be very chatty
App dependencies on static mappings
Pubic in nature (security profile is different – ops often take care of it)
Deployment of applications should be automated (not next next next GUI installs)
Location of resources
Session state and caches

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

LIFT AND SHIFT 70%
Redeploy Apps “As-is”
Simple & Quick
Low- initial cost
Low elasticity

ELASTIC 20%
Load-balance, add OSS infrastructure
Let provider auto-scale
Some refactoring
OPEX savings

CLOUD NATIVE 10%
Designed with the Internet as the OS
Service Composition
Designed for failure
CI/CD

ICONS
Scalability/Elasticity (only the components that need to), Place app anywhere you want based on ‘best fit’ criteria, Reduce costs, Speed/Agility/Time-to-market, Deal with distribution of services and dependencies (from multi-sourcing/cloud model for many apps inc. SaaS consumption).

Address identity management across systems, Make the App accessible in a SaaS fashion (Public/no VPN) + add multi-tenancy to app, Independence (not nailing colours to mast/lock-in), Maximise asset utilisation – only pay for use/need at App level.

Attracting talent/move with the times, Putting the business’ resources in the right places – most value, Add continuity capabilities, Gain visibility – performance, compliance, and metering, App architecture changes can aid resilience of app.
CliQR – Application defined management platform
Platform to model, deploy & manage clouds, applications
Multi-cloud
Model what an application should looks like, a blueprint and build policy & governance around it
Pick the best cloud & 1 click deploy
Visibility and control of cloud usage
Policy
Finance controls
Usage metering
governance
Application migration and management

Common functions of a PaaS
platform and environment to allow developers to build applications
Runtimes environments for various languages
Scaling
Logging
Visibility and health of the app
Show back
Security
Service setup
Helps address previous problems we have mentioned

-----------------------------------------------------------------------------------------------------------

Pivotal + OpenShift  Newer practices and languages  Modernisation is expected
Apprenda  New and Old  Port apps as-is and/or modernise
A Virtual Machine centric world

The “Software-defined Data Centre” isn’t enough here  infra inefficiencies + gap between apps and infra  CliQr = push away from scripting and workflows/orchestration to ‘Application defined, declarative types of control’
Average = 4 Cloud Platforms. 1 in 8 orgs = 7+

CliQr video here

You want to SaaS-ify your app and/or move it to a Cloud platform – your own (and it *might* move to another) or you’re moving straight out to a Provider’s/Public cloud now…Tell a story here:
Moving your applications to ‘cloud’ can be looked upon in the following three ways:
Rewrite the application to exploit the cloud features
Replace the application with a SaaS equivalent
Relocate the application to the cloud environment

1 and 3 are closely tied as far as a steps are concerned with 3 being most prevalent…

Considerations:
Cost of different hosting options – visibility and comparison needed
Technical offerings of different hosting options – visibility and filtering of candidates
Different latencies introduced by Cloud (i.e. the app or a part of it moves somewhere out on the internet off a LAN)  external dependencies? (e.g. AD/LDAP or SQL DB)
Separation of App from its data (data externalisation) to keep it portable
Multi-tenant SaaS HTTP front-end

Refactor?  “backwards-compatible” PaaS means developers can reuse languages, frameworks  e.g. Apprenda
Revise?  Dev project  modify or extend the existing code base to support legacy modernisation requirements, then use rehost or refactor options to deploy to cloud
Rewrite?  Rebuild the solution on PaaS, discard code for an existing application and re-architect the application

Another goal is to expand the ways that users can access Adatum's applications. Currently, applications are only accessible from the intranet. Applications that are located in the public cloud are, by definition, available over the Internet. However, the public cloud also raises questions about authentication. Many of Adatum's applications use Windows authentication so that users aren't required to enter application-specific credentials. Adatum is concerned that its users would need special credentials for each application in the public cloud.
A third goal is that at least some of Adatum's applications should be portable. Portability means that the application can be moved back and forth between a hosted data center and an on-premises data center without any modifications to the application's code or its operations. If both options are available, the risks that Adatum incurs if it does use the cloud are reduced.
In addition to its concerns about security, Adatum has two other issues. First, it would like to avoid a massive retraining program for its IT staff. Second, very few of Adatum's applications are truly isolated from other systems. Most have various dependencies. Adatum has put a great of deal effort into integrating its systems, even if not all of them operate on the same platform. It is unsure how these dependencies affect operations if some systems are moved to the public cloud.
Build applications with cloud in mind
Green field apps
Follows 3 movements
DevOps
CI/CD
Microservices

Common theme is;
build
depoy
run

Much closer to business demand
speed
agility
pay for what use

Automation is critical
Consisitancy between dev environments and production environments
“PaaS Migration is the process of moving from the use of one software operating and deployment environment to another environment, e.g. from an on-premise solution to the cloud”
“Statelessness is a requirement for VMs and applications to be deployable without data.
As a consequence, data externalisation is required to prepare for scale-out, which necessitates externalisation for an efficient management”
of elasticity requirements.“Customers do not manage their virtual machines, but are concerned with middleware components, their development and deployment. They develop and deploy applications within an existing API or programing language. PaaS Migration is the process of moving from the use of one software development and deployment environment to another environment.”
“Two classical software architecture concerns need to be embraced by a PaaS architecture migration process solution:
architecture re-engineering, i.e. the adaptation and modification of a software solution to meet the requirements of elastic and resilient cloud provisioning,
architecture ageing, i.e. the validation and correction of programming and data aspects aiming at incorrect and outdated structures.
Migration Techniques:
Direct deployment to PaaS with limited changes (either the entire application or part of it)
Immediate pay-per-usage and flexibility from provider pov (no good for Enterprise?)
Deployment on PaaS with some level of architectural and/or design transformation
Programming Models for Stateless Programming  elasticity (scale out, run anywhere) and scalability gains
Databases for State Management  elasticity and scalability gains
Data Externalisation for Resiliency  resiliency gains
In case of PaaS, the consumer controls software deployment and configuration settings whereas the provider provides the application runtime environment, development life cycle support tools and other services that are required to host the consumer's application.
PaaS: limited interoperability and lack of common terminology

Fallacies +
Co-location of the application layers and components
Resilience, low latency, and high bandwidth connectivity between layers
Applications disposition for vertical scaling, considering the underutilized infrastructure in traditional
data centers
Performance optimization approach, based on application deployment platform tuning, that relies on fine-grained control over the deployment platform
Use of multiple technologies and frameworks, many of which may be non-standard
Dependence on enterprise level shared services related to security, directory services, data management and so on
Complex application integration scenarios with reliance on multiple architectural patterns
Application design patterns (for example, sticky session, synchronous v/s asynchronous communication)
Architectural patterns needing heavy data traffic within the WAN

“continuous delivery and horizontal architectures”
“provision and bind web and mobile apps with leading platform and data services such as Jenkins, MongoDB, Hadoop, etc.”
HA  Desired State vs. Actual State tracking  New instances if not matching. Restart VMs. Scale into different AZs.
“development and test to staging and production environments with no changes.”
uses common computing resources including hardware, operating system, software (i.e. application code), and a single underlying database with a shared schema to support multiple customers simultaneously
Isolation  i.e. Dev - Test - Prod
Keep it working  auto-scale, economically  Microservice = only scale the bit that needs to scale…
MANTL: Under the Covers

Open source infrastructure agnostic container stack
Deploys to metal, AWS EC2, GCE, DigitalOcean, OpenStack, VMware, etc.
Easy to deploy
Support emerging workloads
Batteries included: built-in security, logging, HA, scheduling, service discovery

Integrates Mesos + HashiCorp Consul
Deployment automation via Ansible
Works out of the box w/ LogStash, collectd, Docker, Calico, GlusterFS, etc.
Developed on GitHub w/ over 1800 stars, 200 forks, 50 contributors

Added Kubernetes support (Kubernetes + Mesos)

Service discovery allows network communication between services. It is an essential configuration step when you wish to run an application distributed across a data center.

All agents can run the DNS or HTTP interfaces, and are responsible for running checks and keeping services in sync.
Client - forwards all RPCs to a server. Performs health checks against services and gossips health state changes.
Server – responds to RPC requests. Exchanges WAN gossip with + forwards queries to other DCs.

Example: graphite.consul.service  Returns a random IP of a live graphite relay node  New nodes?  Register them with Consul and they automatically appear in the list the next time a client resolves that hostname.
You can place Consul “behind” internal DNS servers and forward all requests for the “consul” domain name to a consul agent running on the DNS servers or you can route all DNS requests to the local Consul agent running on each node and have it forward everything “non-Consul” to the DNS servers

Consul holds the location (URI) and health of every service on every host, and makes this data available via multiple channels, such as a REST API and GUI. The API also lets you make complex queries and get the service data segment you’re interested in. For example: Get me all the addresses of all instances of service ‘X’ from Datacenter ‘Y’ in ‘staging env’ (tag).

dnsmasq = Get containers to talk with each another using their names, easily allowing for IP address changes (containers have different IP addresses on start)
Logstash = Forward logs

GlusterFS  Scalable network filesystem  “FUSE” mount  3 copies across distributed filesystem  Dedicated containers/nodes?

Vault for managing secrets
Mesos = efficient resource isolation and sharing across distributed services  Efficient and flexible use of resources
mesos-consul populating Consul service discovery with Mesos tasks  Mesos-consul automatically registers/deregisters services run as Mesos tasks  This means if you have a Mesos task called TechHuddle, this program will register the application in Consul, and it will be exposed via DNS as techhuddle.service.consul  also does Mesos leader discovery, so that leader.mesos.service.consul will point to the current leader

Mantl API easily install supported Mesos frameworks on Mantl (DCOS https://github.com/mesosphere/universe)
Mantl UI a beautiful administrative interface to Mantl  NGINX front-end (proxying)

Kong for managing APIs
MANTL: Under the Covers

Open source infrastructure agnostic container stack
Deploys to metal, AWS EC2, GCE, DigitalOcean, OpenStack, VMware, etc.
Easy to deploy
Support emerging workloads
Batteries included: built-in security, logging, HA, scheduling, service discovery

Integrates Mesos + HashiCorp Consul
Deployment automation via Ansible
Works out of the box w/ LogStash, collectd, Docker, Calico, GlusterFS, etc.
Developed on GitHub w/ over 1800 stars, 200 forks, 50 contributors

Added Kubernetes support (Kubernetes + Mesos)

Service discovery allows network communication between services. It is an essential configuration step when you wish to run an application distributed across a data center.

All agents can run the DNS or HTTP interfaces, and are responsible for running checks and keeping services in sync.
Client - forwards all RPCs to a server. Performs health checks against services and gossips health state changes.
Server – responds to RPC requests. Exchanges WAN gossip with + forwards queries to other DCs.

Example: graphite.consul.service  Returns a random IP of a live graphite relay node  New nodes?  Register them with Consul and they automatically appear in the list the next time a client resolves that hostname.
You can place Consul “behind” internal DNS servers and forward all requests for the “consul” domain name to a consul agent running on the DNS servers or you can route all DNS requests to the local Consul agent running on each node and have it forward everything “non-Consul” to the DNS servers

Consul holds the location (URI) and health of every service on every host, and makes this data available via multiple channels, such as a REST API and GUI. The API also lets you make complex queries and get the service data segment you’re interested in. For example: Get me all the addresses of all instances of service ‘X’ from Datacenter ‘Y’ in ‘staging env’ (tag).

dnsmasq = Get containers to talk with each another using their names, easily allowing for IP address changes (containers have different IP addresses on start)
Logstash = Forward logs

GlusterFS  Scalable network filesystem  “FUSE” mount  3 copies across distributed filesystem  Dedicated containers/nodes?

Vault for managing secrets
Mesos = efficient resource isolation and sharing across distributed services  Efficient and flexible use of resources
mesos-consul populating Consul service discovery with Mesos tasks  Mesos-consul automatically registers/deregisters services run as Mesos tasks  This means if you have a Mesos task called TechHuddle, this program will register the application in Consul, and it will be exposed via DNS as techhuddle.service.consul  also does Mesos leader discovery, so that leader.mesos.service.consul will point to the current leader

Mantl API easily install supported Mesos frameworks on Mantl (DCOS https://github.com/mesosphere/universe)
Mantl UI a beautiful administrative interface to Mantl  NGINX front-end (proxying)

Kong for managing APIs
How does Shipped use Mantl?

Shipped is purpose built to make deploying docker applications super easy, so Mantl was built alongside it to make hosting these applications easy.

Shipped actually runs itself alongside other tenant applications on Mesos workers. Shipped allows developers to build their application into a docker image. Once you have a containerized app, you can deploy with the push of a button. Behind the scenes, this goes something like this:

POST a request to Marathon that starts at least one new task with the docker container. We include some special environment variables that are consulted by HAProxy-Consul later to get hostnames correct.
Marathon-Consul watches the Marathon event bus to update Consul with the running services and the ports they started on.
HAProxy-Consul re-writes the HAProxy configuration to route hostnames to the correct containers (for now this is a round-robin setup).
All the worker nodes run Logstash. It slurps up Mesos logs and output from each container’s stdout/err and forwards them on to Elastic Search. This allows us to make deployment failures. It also gathers logs from every container and makes them available in the management dashboard
CAdvisor collects metrics from each container and sends them to Elastic Search for later consumption.
What could it look like in a very simple format  architecture…
Why Mantl:
Deploy Containers in Production at Scale
Curated stack saves time on design and deployment
100% Open sourced tools – no vendor lock in
Low cost of entry

Add holder for videos

Tech huddle paas_session

You are reading a preview.

Check these out next

Tech huddle paas_session

More Related Content

Slideshows for you (20)

Similar to Tech huddle paas_session (20)

Recently uploaded (20)

Tech huddle paas_session

Editor's Notes

Tech huddle paas_session

You are reading a preview.

Tech huddle paas_session

Recommended

More Related Content

Slideshows for you (20)

Similar to Tech huddle paas_session (20)

Recently uploaded (20)

Tech huddle paas_session

Editor's Notes