Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cost comparison between various deployment systems for non-managed applications #38

Open
jaypipes opened this issue Jun 12, 2018 · 0 comments

Comments

@jaypipes
Copy link
Owner

I'd like to define a comprehensive way of evaluating real-world costs for deploying non-managed applications on a variety of on-prem and off-prem infrastructure.

Non-managed applications are those applications that are not orchestrated via a SaaS system or managed hosting "site platform" ala cPanel.

Non-managed applications need not be proprietary or internal-only code. Open source software like Wordpress and Drupal may be deployed by an internal IT team and managed by the IT or sysops teams. I'd like to provide some real-world numbers to guide these kinds of IT teams in deciding between the tradeoffs of deploying between various infrastructures:

  • On-prem VM infrastructure (OpenStack + VM images)
  • On-prem Container-based (Kubernetes + Docker images, OpenStack + Kubernetes + Docker images)
  • On-prem PaaS (OpenStack + CloudFoundry)
  • Traditional VM-based cloud (AWS, GCE, Azure)
  • Container-based cloud (AKS, GKE, Azure Container Service)
  • Off prem PaaS systems (Heroku)

NOTE: I'm only interested in applications that have some sort of persistent data storage needs. I've yet to meet a single IT manager or operations individual that cared about applications that didn't store or write any data. So... "hello world" or "echo" applications are not going to be discussed in this article.

Discussion points:

  1. Packaging and deployment mechanism
  • VM images vs. Docker images vs buildpacks (Heroku, CloudFoundry)
  • Ease of understanding for non-developers
  • Amount of infrastructure needed to properly use (requirements around a registry, needing to host your own registry, team experience with technology, etc)
  1. Ability to handle change
  • Configuration change and ensuring clear separation of config from application data
  • Ease of integration into CI/CD systems
  • Observability of change events to the administrator and user
  • Performing backup and restore services for data used in the application
  • Ease of expanding/shrinking resource usage as needed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant