Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Comparing Cloud Providers for Application Development

Matt White
September 15, 2016

Comparing Cloud Providers for Application Development

Matt White

September 15, 2016
Tweet

More Decks by Matt White

Other Decks in Technology

Transcript

  1. w w w . l d c v i a

    . c o m Comparing Cloud Providers for Application Development Matt White | LDC Via
  2. w w w . l d c v i a

    . c o m About Me • Domino web developer since the 1990s • Lotus Award winner with IdeaJam • XPages developer since before it was released • node.js and MongoDB developer • Co-founder of LDC Via • http:/ /ldcvia.com • Domino to Cloud data migration and hosting platform
  3. w w w . l d c v i a

    . c o m Agenda • Introduction • Technical Considerations • Legal Considerations • Making Comparisons • Real World Example
  4. w w w . l d c v i a

    . c o m Where are we coming from? • Applications vs Mail • Mail is a commodity at this point • Typically for IBM shops we would run our own hardware and software, usually on premises • Over recent years there has been increasing pressure to move to “the cloud” • [Insert dramatic music here]
  5. w w w . l d c v i a

    . c o m Why move to the cloud? Flexibility Disaster recovery Faster deployment Accounting Easier to access Environmentally friendly Easier to manage Reduced head count (!) Simpler licensing Scalability
  6. w w w . l d c v i a

    . c o m Hold on a second buddy Data loss risks Redesign of applications Legal issues Hidden costs Loss of control Multi-tenancy Increased complexity Political issues Provider consolidation SLAs
  7. w w w . l d c v i a

    . c o m Let’s define some terms • The Cloud • SOA – Service Oriented Architecture • Microservices (buzzword du jour) • IaaS – Infrastructure as a Service • PaaS – Platform as a Service • SaaS – Software as a Service • CaaS – Containers as a Service
  8. w w w . l d c v i a

    . c o m Pizza as a Service • Source: https:/ /www.linkedin.com/pulse/20140730172610-9679881-pizza-as-a-service
  9. w w w . l d c v i a

    . c o m And in the real world • http://cloudacademy.com/blog/cloud-migration-benefits-risks/
  10. w w w . l d c v i a

    . c o m IaaS Paas SaaS Positioning Providers
  11. w w w . l d c v i a

    . c o m Technical Considerations • Development languages • No significant future for Notes and Domino development • Many alternatives: • Java, C#, JavaScript, PHP, Ruby, Python, C++, Perl, Scala, R, Objective C, Swift, Go, Turbo Pascal, LotusScript • Based on the language this will push you in one direction or another for cloud services • Development environment • How do your developers actually do work?
  12. w w w . l d c v i a

    . c o m Technical Considerations • Database • Document • MongoDB • CouchDB • etc… • Or relational • DB2 • SQL Server • etc… • Database service or self managed • Backups
  13. w w w . l d c v i a

    . c o m Technical Considerations • Source Control • Most likely cloud based as well • e.g. Github or Atlassian • Security is very important • How does it integrate with your application hosting platform?
  14. w w w . l d c v i a

    . c o m Technical Considerations • Version Control • You have to worry not just about your own code • You need to keep track of database and server platforms as well • Although you may not actually have any control over them
  15. w w w . l d c v i a

    . c o m Technical Considerations • Testing • Shouldn’t really be any different in process • However • Do you run a test environment that matches your production environment in the cloud? • Have you considered something like Docker to allow you to build consistent environments? • Can your test process be improved to allow continue integration and delivery?
  16. w w w . l d c v i a

    . c o m Technical Considerations • Deployment • Could be far simpler than equivalent on premises deployments • Continuous Deployment is an attainable goal with modern development techniques • Possibly integrated into the platform (e.g. Heroku / Github) • Jenkins • Travis
  17. w w w . l d c v i a

    . c o m Technical Considerations • Security • Who has access to… • Databases • Source Code • Application Logs • How does your application communicate to the database? • How do you authenticate against your corporate directory? • Is your infrastructure visible to the internet at large?
  18. w w w . l d c v i a

    . c o m Legal/Security Considerations • Where is the application hosted? • Is the data allowed to leave your country or region? • By hosting data in the cloud is it opened up to legal issues – Safe harbour? • e.g. data hosted in Europe on US owned platforms • Do your clients know (or care) where the data is hosted? • What happens if there is a security breach? • Disaster recovery options?
  19. w w w . l d c v i a

    . c o m IaaS Comparisons • The main choices are • EC2 • Azure • Google Cloud Platform • Softlayer • Cost is the main differentiator • Followed • your strategic direction • data centre locations • additional offerings • http:/ /www.rightscale.com/blog/cloud-management-best-practices/how-compare-aws-vs- azure-vs-google-vs-softlayer
  20. w w w . l d c v i a

    . c o m PaaS Comparisons • The main choices are • Amazon EC2 • Azure • Heroku • Force.com • The decision point will vary based upon business strategy • May remove the need for any use of IaaS • https:/ /www.g2crowd.com/categories/platf orm-as-a-service-paas
  21. w w w . l d c v i a

    . c o m SaaS Comparisons • Hundreds of choices • Pick the task • Project Management • Accounting • CRM • Etc… • Does your business fit “standard” tools • Be wary of costs building up
  22. w w w . l d c v i a

    . c o m Case Study: LDC Via • We run… • MongoDB • Two different node.js applications • Main application API • Front end application • Codebase sits in Github • Distributed development team • Each run own dev environment • Matching test environment • Monitoring service
  23. w w w . l d c v i a

    . c o m Hosting databases • We use MongoDB, but the same issues hold for other databases • Our main choices • A Database as a Service provider (e.g. mLab) • Very easy to get going • Well managed • Secure • Scalable to a point • Gets expensive quickly
  24. w w w . l d c v i a

    . c o m Hosting databases • Manage our own database infrastructure • More work to manage • Mitigated by MongoDB Cloud management software • We have to run the servers and databases • Analogous to running an on premises infrastructure • Our choice: • Database infrastructure is built using Amazon EC2 • Applications are designed to allow this to be switched to true on premises, or an alternative database host as required.
  25. w w w . l d c v i a

    . c o m Hosting databases • An example of managing your own databases and keeping track of versions • We get a weekly notification of the status of our servers from our MongoDB management service
  26. w w w . l d c v i a

    . c o m API Application • We had 3 obvious choices • Heroku • Bluemix • EC2 • Each had benefits to offer • The PaaS options are easier to get going and manage • EC2 allows more flexible configurations as you build the servers yourself
  27. w w w . l d c v i a

    . c o m API Application • Preferred solution would be to use Heroku • However, we have no way to properly secure the database connection without having the database open to the internet • Same issue applies to Bluemix • Therefore, we use EC2 to host our self managed node servers • EC2 is as close to traditional On Premises admin work as you can find
  28. w w w . l d c v i a

    . c o m Front end Application • Our new offering “KEEP.WORKS” needs to interface with the API Application but doesn’t touch the database directly • So it’s a straight choice between Heroku and Bluemix • In this case Heroku wins because it also runs on EC2, so runs far quicker against the API application. • You need to do research into your providers!
  29. w w w . l d c v i a

    . c o m Monitoring Service • We need to know when a part of the infrastructure goes down • There are many offerings around • e.g. Within PaaS offerings there are often status plugins • SaaS dedicated to monitoring end points • We use a service called Pingdom • In some cases there’s actually not much you can do about downtime
  30. w w w . l d c v i a

    . c o m Nickel and Dimed to Death? • The headline costs of the PaaS offerings is very appealing • A production ready node.js app on Heroku can be as little as $50 per month • But… • What about SSL – extra monthly fee • What about logging – extra monthly fee • What about monitoring – extra monthly fee • It can all mount up very quickly
  31. w w w . l d c v i a

    . c o m Conclusions • Before you start to move to the cloud you need to understand… • What problems you want to solve • What your users need • What your developers want • If done correctly, you can radically improve your ability to provide applications to run your business.
  32. w w w . l d c v i a

    . c o m Useful resources • https:/ /www.cloudorado.com/cloud_server_co mparison.jsp • Compare different providers headline prices • https:/ /clutch.co/cloud • https:/ /www.g2crowd.com/categories/infrastru cture-as-a-service-iaas • https:/ /www.g2crowd.com/categories/platform -as-a-service-paas • https:/ /jenkins.io/ • https:/ /travis-ci.org/ • https:/ /www.docker.com/
  33. w w w . l d c v i a

    . c o m Contact Me • Contact me: • @mattwhite • [email protected] • Download slides at: http:/ /mattwhite.me/presentations