Pro Yearly is on sale from $80 to $50! »

Vito Chin

Dc3da55915948e85e33d752219946d5b?s=47 Vito Chin
October 04, 2015

Vito Chin

PHP and the Liberal Cloud. Presented at PHP Conference Asia 2015.

Dc3da55915948e85e33d752219946d5b?s=128

Vito Chin

October 04, 2015
Tweet

Transcript

  1. PHP AND THE LIBERAL CLOUD Vito Chin

  2. Vito Chin (@vitoc) • Lead, Development & Test at Singtel

    • Enterprise cloud utilisation • Cloud best practices • Gmagick PHP extension • Co-author of PHP Development in the Cloud
  3. Outline • Preface • History • Cloud definitions • Liberty

    • PHP and cloud liberty
  4. Preface

  5. –PHP 7 engine improvments http://talks.php.net/singapore15#/php7 "100%+ performance gain on most

    real-world applications"
  6. History

  7. None
  8. None
  9. Definitions

  10. http://www.nist.gov/itl/cloud/ “Cloud computing is a model for enabling convenient, on-demand

    network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models.”
  11. Essential Characteristics 1. On-demand self-service 2. Broad network access 3.

    Resource pooling 4. Rapid elasticity 5. Measured service
  12. Service Models 1. Infrastructure As A Service 2. Platform As

    A Service 3. Software As A Service
  13. Deployment Models 1. Private 2. Community 3. Public 4. Hybrid

  14. Where should I run my PHP?

  15. Typical choices of tools, vendors and services providers Amazon Web

    Services Jelastic Alatum EngineYard Azure Aliyun Softlayer Digital Ocean Linode Google Cloud OpenStack fortrabbit Heroku
  16. The Hype Cycle 2015 State of Cloud IaaS SaaS PaaS

  17. None
  18. Liberty?

  19. Positive liberty • 'What, or who, is the source of

    control or interference that can determine someone to do, or be, this rather than that?' (Isaiah Berlin) • Liberty to choose the 'source of control' • You should be free to choose the entity (vendor, organisation, etc) that ensures continuous operation of your IaaS, PaaS or SaaS based on your preference of its operating environment.
  20. Negative liberty • 'What is the area within which the

    subject — a person or group of persons — is or should be left to do or be what he is able to do or be, without interference by other persons' (Isaiah Berlin) • The absence of coercion or interference with agents' possible private actions, by an exterior social-body. • Are your PHP applications constrained by the extensions that are available on the platform in which it resides on? • What should your PHP application be able to do on a specific cloud environment? • Should you choose an IaaS or a PaaS? • Does the cloud vendor's environment influences your decision on how to run your application?
  21. Positive liberty

  22. Mobility • Freedom of movement • Liberty to choose "source

    of control" • How sure are you that your application possess this trait? • Can your application be hosted on Azure App Service just as easily as it is hosted on AWS EC2 or Heroku?
  23. AWS Virtual Servers Containers Event-driven compute Auto-scaling Object storage Block

    storage File system storage Archive storage Relational DB NoSQL Caching Hadoop Machine Learning Real time data stream Data warehouse Data pipeline Resource creation Workflow Streaming Transcoding Email Search API management Mobile notification Application management
  24. AWS Virtual Servers Containers Event-driven compute Auto-scaling Object storage Block

    storage File system storage Archive storage Relational DB NoSQL Caching Hadoop Machine Learning Real time data stream Data warehouse Data pipeline Resource creation Workflow Streaming Transcoding Email Search API management Mobile notification Application management Harder to move out Easier to move out
  25. Negative liberty

  26. The lure • Convenience (and speed) • Security (and assurances)

  27. Unix philosophy • Rule of Economy: Programmer time is expensive;

    conserve it in preference to machine time. • Rule of Optimization: Prototype before polishing. Get it working before optimisation.
  28. Convenience - Example: auto-scaling • Mostly a DevOps & TechOps

    concern • AWS and Azure for example, provides convenient means to auto-scale your application or service • Application / development needs to minimally conform to auto-scalable cloud's "way of doing things"
  29. AWS auto-scaling "WebServerGroup" : { ! "Type" : "AWS::AutoScaling::AutoScalingGroup", !

    "Properties" : { ! "AvailabilityZones" : { "Ref" : "AZs" }, ! "VPCZoneIdentifier" : { "Ref" : "Subnets" }, ! "LaunchConfigurationName" : { "Ref" : "LaunchConfig" }, ! "MinSize" : "1", ! "MaxSize" : "10", ! "DesiredCapacity" : { "Ref" : "InstanceCount" }, ! "LoadBalancerNames" : [ { "Ref" : "ElasticLoadBalancer" } ] ! }, .....
  30. AWS auto-scaling "LaunchConfig" : { ! "Type" : "AWS::AutoScaling::LaunchConfiguration", !

    "Metadata" : { ! "Comment" : "Install a simple application", ! "AWS::CloudFormation::Init" : { ! "config" : { ! "packages" : { ! "yum" : { ! "httpd" : [] ! } ! }, .....
  31. What's given away? • Conform to AWS' way of doing

    things: • CloudFormation template • Security groups • Config and package handling • Scaling conditions • Etc.
  32. How dependent are you? • How long does it take

    to setup an (almost) similar auto-scaling environment in Azure or Digital Ocean? • How do you package your application? • .deb, .rpm • AMI or other image • git pull ... • How did you design your application? • Stateless web, app or worker roles • Shared persistency
  33. Creeping normality as described in Wikipedia "A major change can

    be accepted as the normal situation if it happens slowly, in unnoticed increments, when it would be regarded as objectionable if it took place in a single step or short period."
  34. Security • High availability • SLAs • Fault tolerance •

    DDoS mitigation • Geographic residency
  35. –Benjamin Franklin "Those who would give up essential Liberty, to

    purchase a little temporary Safety, deserve neither Liberty nor Safety."
  36. More Unix philosophy • Rule of Diversity: Distrust all claims

    for “one true way”. • Rule of Extensibility: Design for the future, because it will be here sooner than you think.
  37. Preserving freedom • Abstractions • Open platforms • 12-factor

  38. Abstractions

  39. Laravel 'default' => 'beanstalkd', 'connections' => [ ... 'database' =>

    [ 'driver' => 'database', 'table' => 'jobs', 'queue' => 'default', 'expire' => 60, ], 'beanstalkd' => [ 'driver' => 'beanstalkd', 'host' => 'localhost', 'queue' => 'default', ... ... ], 'sqs' => [ 'driver' => 'sqs', 'key' => 'your-public-key', 'secret' => 'your-secret-key', 'queue' => 'your-queue-url', 'region' => 'us-east-1', ], 'iron' => [ 'driver' => 'iron', 'host' => 'mq-aws-us-east-1.iron.io', 'token' => 'your-token', 'project' => 'your-project-id', 'queue' => 'your-queue-name',
  40. Open platforms

  41. Cloud Foundry AWS OpenStack vSphere vCloud Air ... OpenShift

  42. PHP on Cloud Foundry • Cloud-native application design • Open

    source • Cloud Foundry environment variables • $services = getenv("VCAP_SERVICES"); $services_json = json_decode($services,true);
  43. Roll-your-own Docker Salt Vagrant Packer Ansible Open source Terraform Ansible

    Deis Kubernetes
  44. 12-factor app PaaS helps!

  45. 2. Explicitly declare and isolate dependencies • Never assume the

    existence of a particular extension or package • Declare dependencies explicitly • composer.json • PHP CompatInfo • Package into .deb or .rpm • Provides you with baseline caveats on which cloud is best for your application and exposes any dependency that may be detrimental to liberty
  46. 3. Store config in the environment • Strict separation of

    config from code • Database, cache, queue, email, etc. • Store on environment variables • Reduce the pyschological encumbrance to switching cloud operating options • E.g. switch between an environment distributed among multiple cloud vendors to environment in a private cloud • Environment variables independently managed for each deploy
  47. 4. Treat backing services as attached resources • Makes no

    distinction between local and third party services • A deploy of the twelve-factor app should be able to swap out a local MySQL database with one managed by a third party (such as Amazon RDS) without any changes to the app’s code • Only the resource handle in the config needs to change • In practice, we also need to consider constraints such as latency when connecting to a third party service. I.e. App on Azure connecting to RDS on AWS is probably non-optimal • In any case, the ability to attach and detach resources to deploys at will contributes to mobility in the cloud by making it simpler and faster to deal with change in backing resources. • Reflects trend: a lot of what is traditionally managed by system administrators are now available as managed SaaS
  48. @vitoc

  49. Attribution • https://commons.wikimedia.org/wiki/ File:The_Claddagh_Ring_pub.jpg • https://commons.wikimedia.org/wiki/ File:Gartner_Hype_Cycle.svg • https://commons.wikimedia.org/wiki/ File:Devops.svg

    • http://12factor.net by Adam Wiggins