...
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 insdie inside the code. | Dynatrace | 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. |
| |||||
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. | Amazon AWSn/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 Receipt | I currently have a gap here of how this would work. | |||||||
Source Control for Code |
| |||||||
Packer | ||||||||
External Log Aggregation | Remove infrastructure dependency. | |||||||
Caching System | ||||||||
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 system from a 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) | ||||||
Vagrant |
...