O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

[Srijan Wednesday Webinars] How to Build a Cloud Native Platform for Enterprise Drupal Applications

102 visualizações

Publicada em

Drupal has been a consistent leader in the Gartner Magic Quadrant for Web Content Management. However, enterprises leveraging Drupal have traditionally relied on PaaS providers for their hosting, scaling and lifecycle management. And that usually leads to enterprise applications being locked-in with a particular cloud or vendor.

As container and container orchestration technologies disrupt the cloud and platform landscape, there’s a clear way to avoid this state of affairs. In this webinar, we discuss why it's important to build a cloud-native Drupal platform, and exactly how to do that.

Join the webinar to understand how you can avoid vendor lock-in, and create a secure platform to manage, operate and scale your Drupal applications in a multi-cloud portable manner.

Key Takeaways:
- Why you need a cloud-native Drupal platform and how to build one
- How to craft an idiomatic development workflow
- Understanding infrastructure and cloud engineering - under the hood
- Demystifying the art and science of Docker and Kubernetes: deep dive into scaling the LAMP stack
- Exploring cost optimization and cloud governance
- Understand portability of applications
- A hands-on demo of how the platform works

Publicada em: Tecnologia
  • Get Your Ex Back Today, Relationship expert Justin Sinclair, shows you how with 3 easy steps. ♥♥♥ http://goo.gl/FXTq7P
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
  • Seja a primeira pessoa a gostar disto

[Srijan Wednesday Webinars] How to Build a Cloud Native Platform for Enterprise Drupal Applications

  1. 1. How to Build a Cloud Native Platform for Enterprise Drupal Applications Pavan Keshavamurthy , Head of Enterprise Architecture, DevOps & Cloud Practice Girish Kumar, Senior Cloud/Infrastructure Architect #SrijanWW | @srijan
  2. 2. Introductions Pavan K leads Srijan's Enterprise Architecture, Cloud & DevOps Practice. His charter within Srijan is to engage customers and teams in a consulting/advisory role, particularly around areas concerning platform building & microservices architectures. Girish is a Sr Cloud / Infra Architect with 10+ years of experience. He has had prior stints an Infrastrcutre / DevOps Engineer in FiberLink (IBM), SAP and several startups before joining Srijan. At Srijan he leads multiple projects with a focus around cloud engineering for various classes of workloads.
  3. 3. Enterprise Architecture ● Platform Engineering ● Cloud Engineering ● API Management ● Microservices ● Agile & DevOps SRIJAN is a full lifecycle digital engineering firm. We specialize in enterprise product & platform innovation, fuelled primarily on open source & cloud technologies. Our customers say we run software delivery like a hospitality business. Digital Engagement ● Enterprise Content Management ● Portals ● Front-end engineering Data Science ● Analytics ● Machine Learning ● Data Engineering ● Chatbots ➔ 15+ years of profitable growth ➔ 10+ Multi-year enterprise customers ➔ Global consulting & delivery: HQ’d in India with operations across America, EMEA, APAC ➔ 300+ Headcount ➔ Thriving culture of Agility, Engg & Open Source Contributions ∞
  4. 4. About this session This session is relevant for you if you are: ● An IT / Business stakeholder responsible for the development and operations of Drupal projects ● An infrastructure or cloud engineer curious to gain a worldview around running Drupal on the cloud ● A Drupal developer / application engineer who loves to dabble with things on the ops side. ● A Drupal Company / Managed Services Org that builds (OR) maintains a number of Drupal sites What you will learn during this session: ● Gotchas around “running” Drupal ○ By yourself vs NOT ○ When to & when NOT to ● Def: ○ “Platform” ○ “Cloud Native” ● LAMP stack Gotchas ○ On Docker Containers ○ Kubernetes (a full refresher) ● How to build and run your own
  5. 5. Before we go ahead: A Quick recap on Drupal ● Formerly a Content Management System ○ With D8 - Evolved to a Symfony-esque Content Management Framework” ● Amongst the most popular OSS projects in the world: Active community of 100K+ contributors with a plugin ecosystem of 40K+ ● Powers a whole range of web applications in diverse domains: Gov, Media/Entertainment, Education, Publishing, Non profits Consumer Internet unto high tech ● Mature ecosystem of service providers: Single-person studios to SIs with whole units focussed on Drupal development Powering in excess of 1M sites. > 2% of websites on the entire internet
  6. 6. ..and Docker & Kubernetes ● Docker: De-facto standard for containers. Tiny footprint vis-a-vis conventional VMs. Shared kernel and separated user space ● Kubernetes: De-facto standard for container orchestration (born at Google) ○ Containers need management = distributed systems problem ○ Manage lifecycle of containers, distribution, scheduling, command & control, etc ● Together: de-facto standard for cloud abstraction. Ability to run on any cloud without binding to IaaS primitives
  7. 7. Running Drupal Source: Drupal runing on RPi, https://blog.adafruit.com/2015/06/12/introducing-the-dramble-raspberry-pi-2-cluster-run ning-drupal-8-piday-raspberrypi-raspberry_pi/ PaaS: Aka you build it, they run it Public Cloud IaaS: You build it; you also run it Run it on your own infra: (aka eating your own dogfood)
  8. 8. Hosting Options: Comparison PaaS Platform ability to provision and spawn environments. Your teams concentrate on building and not running Scalability concerns are a platform issue Security is a joint responsibility model (platform security is PaaS responsibility, Application Security is your responsibility) PaaS gives you basic lifecycle management tooling: Building and deploying is via UI or higher level APIs PaaS gives you run tooling: monitoring, DR, support (along with SLAs: 99.xxx) Usually restrictive on what you can run: Constraints plus lock in $$. Expensive. IaaS + nX. IaaS You're responsible for both building and running Scaling up and scaling out are your problems Security is a joint responsibility with IaaS (You're also responsible for "security in the cloud" alongside application security) Build your own You're all on your own Run whatever you want (aka control on own destiny) Just IaaS. Very significant cost savings at scale
  9. 9. There’s a third option Build your own platform *. * ➔ If you have a business case: ex, high volume application, high traffic, polyglot architecture etc ➔ In general, you have control or cost requirements meritorious of building one ➔ If you already have a sizable investment in public/private cloud and have an ops team (even if for security governance & compliance only) with capacity available
  10. 10. Cloud Platforms Platform: What must one do? A wishlist 1. Provide a layer of abstraction above IaaS 2. Ecosystem: Deliver agile, efficient and effective experiences for a. Developers b. Operators 3. Handle cross cutting concerns 4. Scale 5. Secure
  11. 11. Cloud Native Cloud Native is a foundational & prescriptive methodology towards designing and building applications that are meant to run in the cloud. Strongly internalises Agile, DevOps and modern, resilient software architectures like microservices
  12. 12. Cloud Native and Drupal: An aspirational model ➔ Drupal ideally as a containerized stack ➔ Running on LAMP/LEMP, well governed base images (host OS provisioning, container golden images) ➔ Developers have idiomatic experience: Can build high fidelity local environments easily ➔ Minimal or No Ops: CI/CD systems do the hard work ➔ Distributed / Bucket Filesystem. Docroot is ideally immutable and read-only ➔ Public / Private Files Externalized (such as S3 or abstracted from block device - S3 fuse fs) ➔ Take advantage of PaaS services: For Databases, Cache Stores, Load Balancers, Queues, Gateways, etc. ➔ Run on any cloud (or lift & shift with minimal overhead) ➔ Scale up, Scale out and Scale down ➔ An operational model: provisioning new applications, routing, monitoring, releases, deployment
  13. 13. Drupal Platforming Concerns ● Logical Architecture ● Stack Topology: Physical & Security Architecture ● Local Development ● Dev & Build Tools ● CI & Delivery Pipeline ● Monitoring & Management
  14. 14. Part A: The first thing: LAMP Stack architecture A typical LAMP stack application architecture. Docker provides the additional benefit of a host agnostic runtime and a way to govern autonomous local development. High fidelity environments. Aka what you build is what you deploy.
  15. 15. A second step: Deeper dive into LA|E|MP concurrency model Apache Concurrency Model options Nginx: Typical PHP runtime model
  16. 16. Summary - Alignment of the right concurrency model is critical to scale - Apache prefork for example is the easiest setup, but is notorious for resource leakage - Art & science HA setup involves often multiple pieces: Reverse Proxies, Reverse Proxy Load Balancers, Process model (processes vs threads), Networking (TCP/IP vs Unix Socket). - KPIs: Process size in compute, I/O, network terms. Exploratory analysis with load patterns will help you benchmark and test frontiers of stress - Build observability into the system to ensure you application / platform is properly instrumented and debuggable for underlying platform issues so you deal with problems empirically
  17. 17. Part B: Physical / Virt Layer (Example: AWS)
  18. 18. Part B: Physical / Virt Layer (Example: Azure)
  19. 19. Part B: Summary - Network & Secure Virt/Physical Architecture is a key foundational step - Size and design your network - For Availability - Subnets by function (and access at such) - Secure your network - Almost all IaaS support some form of IAC and templating systems. CloudFormation, ARM, Terraform etc. - Consider a shared services network peered for concerns including monitoring / telemetry / deployments and more - For modern API applications with decoupled front-ends, strongly consider an ingress service (such as an API gateway) for handling various cross cutting concerns
  20. 20. Part C: Developer Workflow: Local Development / Build Tools
  21. 21. Part C: Summary (constituents of idiomatic developer experience) ➔ Utilities to setup your environment: including (anonymized) databases. Time To First Line of Code is the best heuristic of developer experience ➔ Galaxy of static code analysis tooling: Sonarqube, PHPMD, PHPCS, TaintPHP; Eliminate garbage. ➔ IDE or Editor experience: Importantly, with debugging tooling (xdebug) ➔ Package management tooling: Composer, drush etc ➔ Drush: Important! (Drush aliases for your local environment) ➔ Check -> build -> test -> push idiom ➔ Your CI implements your local build idiom thus providing parity between what happens locally and what happens remotely
  22. 22. Part D: CI / CD pipelines: Spinnaker
  23. 23. Deployment Models
  24. 24. Part D: Summary (CI/CD) ➔ Adopt (preferably) a GitOps style model: VCS as the single source of truth ➔ CI/CD in the context of Kubernetes. Artefacts are ◆ K8S Object Manifests (deployments, helm charts) ◆ Containers (in a registry) ➔ Separate build / bake / deploy ➔ Separate build and run (prod - non prod) ➔ You should be able to declaratively implement deployment strategies (aka, don’t engineer this yourself - use Spinnaker, if you can) ➔ Spinnaker is not a replacement for your task runner / automation tooling: Can be complementary to Jenkins (infact, leverages Jenkins for builds as a proxy), GitLab CI or others ➔ Mitigate risks: Have a responsible development process, but ability to rollback (hard, with databases), rollforwards, hotfixes. Have SOPs in place including a DR strategy
  25. 25. Part E: Monitoring
  26. 26. Part E: Summary (Monitoring) ➔ Instrument your applications: Log stream telemetry. Without this, you’ll be on YOLO mode. ➔ You’ll need some form of a monitoring agent to collect log telemetry for analysis. If you can afford it, a paid service is great: ex, NewRelic, Nagios etc. Better still, your cloud provider already provides a manged service that can be leveraged with APIs (ex: CloudWatch, OMS etc) ➔ A network level monitor, ingress/service mesh/api gateway is a huge plus, particularly in cases where Drupal is part of a constellation of microservices ➔ Otherwise, a standard ELK|EFK stack is useful. ➔ Cluster / Infra KPIs with Kubernetes is a breeze. Prometheus, Grafana, Sysdig, InfluxDB are standard tooling. cAdvisor, Heapster provide advanced container level telemetry. Most of these tooling can be deployed as services (which watch API server) OR DaemonSets (watch nodes directly) ➔ Prometheus provides an excellent AlertManager; SysDig provides advanced tooling like behavioural analysis (Falco) ➔ Overall galaxy of monitoring tooling is vast. Awareness of key risks, KPIs and a strong operational model (tailored for your needs) is necessary. This intersects people & process concerns as well
  27. 27. <DEMO>
  28. 28. </> Questions? (Srijan also provides consulting, advisory and implementation services for Drupal and other platforming concerns)
  29. 29. Contact Us Know More www.srijan.net business@srijan.net