...
There are many ways to build a Cloud and there are also various levels of clouds.
Legend,
Colour | Note |
---|---|
De Facto Leader Emerged | |
Immature | |
This table aims to cover the key aspects and list various options from top down to then then implement using Path to Cloud,.
Component | Why You Need It | What Does it Do | Driving Cloud Concept | BonsaiFramework Pick | Popular Options | ||
---|---|---|---|---|---|---|---|
Synthetic Monitoring |
| ||||||
Health Check | |||||||
System Monitoring | |||||||
Application Insight Monitoring | Look inside the code to determine performance and support Production problems inside the code. | n/a | Microsoft Azure - Application Insight (free and poweful) Dynatrace was previous winner for stand alone. |
| |||
DOS and DDOS Mitigation | There is some argument that going true cloud no longer requires this. I'm not convinced. | n/a | Akamai. However, for smaller implementations Cloud Provider built-in services may be enough. |
| |||
Customer Caching | Take load off of your system. | Elastic to grow and shrink as needed. | Akamai. However, for smaller implementations Cloud Provider built-in services may be enough. |
| |||
Orchestration of Containers & Service Discovery | Unified view and control of containers who should hook themselves up and configure to the larger group. | Elastic to grow and shrink as needed. |
| ||||
Application Packaging | Means to create application packages and manage centerally. |
| |||||
Software Defined Network | Infrastracture as Code. | Cloud Provider Module or Container Technology |
| ||||
Virtualization Cloud Provider | No point in running the hardware and base OS yourself. Instead use a provider that will take care of auto-scaling hardware, providing IP addresses, storage and a network infrastructure. Bonus points for instituted caching and monitoring. ++ Bonus points for an proven CICD system. Some of the Bonus items you can implement yourself and are documented higher in this stack. | n/a | At the moment (2016) Microsoft Azure for ease of use. |
| |||
Environment Configurator | If you have lots of integration points, centralizing one place to configure those small differences suddenly becomes cost effective. This is not actually service discovery (though having it helps immensely) | Remove infrastructure dependency. |
| ||||
Continous Testing | |||||||
Continuous Deployment | When build completes auto deploy and hook up. |
| |||||
Continuous Build | Building Application Virtualization from Recipes. Think entire ecosystem (not just code) is built from recipes. |
| |||||
Source Control for | Container ReceiptI currently have a gap here of how this would work. | Source Control forCode | GitHub |
| |||
PackerExternal | |||||||
Centralized Log Aggregation | Simplification of adapters to be pipeline will likely emerge as part of Cloud Providers and container technology. | Remove infrastructure dependency. | Splunk | ||||
Application Caching System | Lots of noSQL databases in this space. | ||||||
Messaging System | Guarantee delivery and integrity of key transactions across systems. | Depends on your specific messaging needs. Will break this up later. |
| ||||
Application Virtualization | Microservices concept of running ephemeral containers at the focusing on escapulating a single immutable application. |
| Docker |
| |||
Building Operating Virtualization from Recipe | Build from recipe. |
| |||||
Optimized Operating System for Containers | Newish concept of lightweight transactionally updated operating system. Solaris had the transactional aspect a whle back. |
| |||||
Distributed Operating System for Containers | Similar in concept to what Hadoop technology solves for databases. |
| |||||
Operating Virtualization | I would put this to a specific use case and it can greatly reduce costs (explain here). | LXD (LXC) |
...