12-factor applications using WAS Liberty, IBM Bluemix, and Docker
Download as PPT, PDF0 likes763 views
The document is a practical guide on creating 12-factor applications using IBM's WebSphere Liberty on Bluemix, highlighting the methodology designed for building scalable software-as-a-service applications. It details the twelve factors that improve application portability and cloud readiness, emphasizing best practices for managing dependencies, configurations, and processes. The guide provides specific implementation advice and practical resources, including links to sample applications and core services relevant to the 12-factor methodology.
12-factor applications using WAS Liberty, IBM Bluemix, and Docker
- 1. Creating 12-Factor Applications with WAS Liberty on Bluemix A Practical Guide Erin Schnabel schnabel@us.ibm.com @ebullientworks
- 2. What are Twelve Factor applications? • “a methodology for building software-as-a-service applications” – Created by the developers at Heroku • The Twelve Factors can be applied to applications – In any programming language – With any backing services (or cloud provider.. ) • http://12factor.net/
- 3. Why should you care? • The 12 Factor app is a methodology for building applications that: – Use declarative formats for setup automation – Have a clean contract with the underlying OS – Are suitable for cloud deployment – Has minimum divergence between development and test environments – Can scale up without significant work • Ultimately, it is portable, perfect for running in the cloud and can be maintained in a continuous delivery pipeline MICROSERVICES 3
- 4. 12-Factors + Liberty = ♥ • Twelve-Factor Application: – https://github.com/WASdev/sample.microservices.12factorapp – http://wasdev.net/docs/creating-a-12-factor-application-with-was-liberty • Simple application built to demonstrate all of the factors • Application sample is: – A war with code, and – A packaged liberty server with confg
- 5. Game ON! • Microservices-based application • Enables developers to experiment with microservices concepts • Core set of services written in Java, JavaScript • Java services built upon the 12-factor sample as a base • http://game-on.org • http://wasdev.net
- 7. Factor 1 - Codebase • “One codebase tracked in revision control, many deploys”-12factor.net • Key points – One-to-one correlation between codebase and the app • ‘If there are multiple codebases, it’s not an app – it’s a distributed system” – Codebase is the same across environments: dev, staging, production • Options – Git, Subversion, Mercurial, … • Does this really mean one repository per service? 7 http://12factor.net
- 8. Factor 2 - Dependencies • “Explicitly declare and isolate dependencies”-12factor.net • Key points: – App declares all dependencies, completely and exactly – App does not rely on “pre-requisite” system-wide packages – Use dependency isolation tool, e.g. gradlew • Implementation: – Docker vs. CF – gradlew for ensuring the correct version of gradle 8
- 9. Factor 3 - Config • “Store config in the environment”-12factor.net • Key points: – Config includes anything that can vary between deploys – Does not include internal application config – e.g. features in Liberty • How we implemented this: – Environment variables for Containers – For Bluemix: environment variables via a yaml file or VCAP_SERVICES 9
- 10. Factor 4 - Backing Services • “Treat backing services as attached resources”-12factor.net • Key points: – Backing services Datastore, Watson, …. – Resources can be attached and detached at will • How we implemented this: – Location of the database stored in environment variables • VCAP_SERVICES or Bluemix environment yaml file • Fetched from etcd as config store 10
- 11. Factor 5 – Build, release, run • “Strictly separate build and run stages”-12factor.net • Key points: – Strict separation between the three stages: Build, Release, Run – e.g. no code changes at runtime • How we implemented this: – Build pipeline! Git commit to master build live! – Local: gradle/maven + docker-compose 11
- 12. Factor 6 - Processes • “Execute the app as one or more stateless processes”-12factor.net • Key points: – 12-Factor processes are stateless and share-nothing – Never assume that anything cached will be available on a future request • Options – Use a datastore or shared cache to store data that needs persisting – Provides advantages in terms of scaling 12
- 13. Factor 7 – Port Binding • “Export services via port binding”-12factor.net • Key points: – App is completely self-contained – “…The web app exports HTTP as a service by binding to a port,…” *** – Host and port should be provided by the environment • Options – Liberty server variables: Bluemix routing vs. local environment – Liberty server package is an ideal self-contained unit. 13
- 14. Factor 8 - Concurrency • “Scale out via the process model”-12factor.net • Key points: – Recommends splitting processes based on the type of work • Request-driven (HTTP) vs. long running / background tasks – Scale by making more processes • Our implementation: – Use Bluemix for scaling – via dashboard or Autoscaling Service 14
- 15. Factor 9 - Disposability • “Maximize robustness with fast startup and graceful shutdown”-12factor.net • Key points: – The 12-factor app's processes are disposable – Strive to minimize startup time – Robust against 'sudden death' • Liberty provides fast startup and graceful shutdown – Use normal EE container lifecycle 15
- 16. Factor 10 – Dev/Prod parity 16 • “Keep development, staging, and production as similar as possible” -12factor.net • Key points: – Use the same (or very similar) services for dev and production – Dev/prod parity especially important for backing services • What we did : – Docker Containers (docker-compose) for required services (locally) – Run in WDT locally vs. CF runtimes on Bluemix for production
- 17. Factor 11 - Logs • “Treat logs as event streams” -12factor.net • Key points: – A 12-factor app never concerns itself with routing or storage of its output stream – Process streams are captured by the execution environment • Strict adherence: – set com.ibm.ws.logging.trace.file.name=stdout in bootstrap.properties • More common – Use <toolOfChoice> to read/forward log files Liberty creates 17
- 18. Factor 12 – Admin processes 18 • “Run admin/management tasks as one-off processes”-12factor.net • Key points: – Keep admin task code with application code – Run admin tasks in an identical environment to the app • Run against a “Release” / Same config – Same dependency isolation: gradlew, bundle exec, python virtualenv
- 20. In Conclusion… • Most factors have a variety of implementation options • Keeping the factors in mind gives us an application that: – Can be managed in a continuous delivery pipeline – Is a good candidate for microservices architecture • There may be situations where you don't want to follow the rules
- 21. Questions?
- 22. Notices and Disclaimers 22 Copyright © 2016 by International Business Machines Corporation (IBM). No part of this document may be reproduced or transmitted in any form without written permission from IBM. U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM. Information in these presentations (including information relating to products that have not yet been announced by IBM) has been reviewed for accuracy as of the date of initial publication and could include unintentional technical or typographical errors. IBM shall have no responsibility to update this information. THIS DOCUMENT IS DISTRIBUTED "AS IS" WITHOUT ANY WARRANTY, EITHER EXPRESS OR IMPLIED. IN NO EVENT SHALL IBM BE LIABLE FOR ANY DAMAGE ARISING FROM THE USE OF THIS INFORMATION, INCLUDING BUT NOT LIMITED TO, LOSS OF DATA, BUSINESS INTERRUPTION, LOSS OF PROFIT OR LOSS OF OPPORTUNITY. IBM products and services are warranted according to the terms and conditions of the agreements under which they are provided. Any statements regarding IBM's future direction, intent or product plans are subject to change or withdrawal without notice. Performance data contained herein was generally obtained in a controlled, isolated environments. Customer examples are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual performance, cost, savings or other results in other operating environments may vary. References in this document to IBM products, programs, or services does not imply that IBM intends to make such products, programs or services available in all countries in which IBM operates or does business. Workshops, sessions and associated materials may have been prepared by independent session speakers, and do not necessarily reflect the views of IBM. All materials and discussions are provided for informational purposes only, and are neither intended to, nor shall constitute legal or other guidance or advice to any individual participant or their specific situation. It is the customer’s responsibility to insure its own compliance with legal requirements and to obtain advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulatory requirements that may affect the customer’s business and any actions the customer may need to take to comply with such laws. IBM does not provide legal advice or represent or warrant that its services or products will ensure that the customer is in compliance with any law
- 23. Notices and Disclaimers Con’t. 23 Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products in connection with this publication and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. IBM does not warrant the quality of any third-party products, or the ability of any such third-party products to interoperate with IBM’s products. IBM EXPRESSLY DISCLAIMS ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. The provision of the information contained h erein is not intended to, and does not, grant any right or license under any IBM patents, copyrights, trademarks or other intellectual property right. IBM, the IBM logo, ibm.com, Aspera®, Bluemix, Blueworks Live, CICS, Clearcase, Cognos®, DOORS®, Emptoris®, Enterprise Document Management System™, FASP®, FileNet®, Global Business Services ®, Global Technology Services ®, IBM ExperienceOne™, IBM SmartCloud®, IBM Social Business®, Information on Demand, ILOG, Maximo®, MQIntegrator®, MQSeries®, Netcool®, OMEGAMON, OpenPower, PureAnalytics™, PureApplication®, pureCluster™, PureCoverage®, PureData®, PureExperience®, PureFlex®, pureQuery®, pureScale®, PureSystems®, QRadar®, Rational®, Rhapsody®, Smarter Commerce®, SoDA, SPSS, Sterling Commerce®, StoredIQ, Tealeaf®, Tivoli®, Trusteer®, Unica®, urban{code}®, Watson, WebSphere®, Worklight®, X-Force® and System z® Z/OS, are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at: www.ibm.com/legal/copytrade.shtml.
- 24. Thank You Your Feedback is Important! Access the InterConnect 2016 Conference Attendee Portal to complete your session surveys from your smartphone, laptop or conference kiosk.
Editor's Notes
- #5: When you look at the website, all of the factors are very abstract Easiest way to understand them is by trying to implement them That&apos;s where our application comes in Data persistence service for some polling application Ultimately a bit noddy at the moment, in reality it would have some function like creating API keys Accessed via REST Stores data in Cloudant Deployed to Bluemix We defined the application to be a war with code and a packaged Liberty server with config, more about why later Check out github and wasdev Do quick demo here
- #8: We chose git, as its very popular at the moment, new and exciting Another version control option is to use the Bluemix Devops pipeline which combines version control with planning a deployment tools to provide a continuous development and delivery pipeline (git based) During our discussions of this factor the question was raised, does this mean we have to have a separate repository for each app. E.g. in a microservice situation does each service have it&apos;s own repo The key point from this factor is the one-to-one correlation so actually you could put all the code for your services in one repository but you have to make sure that the code does not overlap, that you have clearly defined boundaries between the code for different services.
- #9: We used Maven and Gradle, dependencies are explicitly declared in the build script and get pulled down at build time Some of the dependencies we declare in the build scripts are only for compile, we require Liberty features at runtime This is where it became clear that we should package Liberty, our app depends on the Liberty features to run, e.g. servlet-3.1, jsonp-1.0 and jaxrs-2.0, so these should be declared and included in our app Liberty features are explicitly declared in server.xml Conforming to this factor makes your application more portable