3 ms·
The cloud providers haven't closed the DevOps loop yet is why. I mostly have experience with Google's stuff, so I will take Cloud Build as an example. It prov
by benlivengood 4y ago
The cloud providers haven't closed the DevOps loop yet is why. I mostly have experience with Google's stuff, so I will take Cloud Build as an example. It provides the framework of CI/CD, but there isn't automatic build+deploy for every software and framework ecosystem.
What I'm trying to do at work is simplify the build ecosystem for all languages to the familiar `configure ; make ; make test ; make install` sequence that works well for OSS. If every ecosystem fit into that metaphor then the loop could be closed pretty effectively by any cloud provider by letting users add repositories to the CI/CD framework and it would do e.g. a standard docker build (configure, make, test), docker push (make install 1/2), and kubectl rollout to k8s at the end (remainder of make install).
Blockers:
Liveness and readiness checks are not automatic; they need to be part of each language*framework so that developers don't have to implement them by hand. At Google they just sort of came with the default HTTPServer class in your language of choice, with callbacks or promises you knew you had to invoke/complete when the instance was ready to serve. It helped that only 4 languages were officially supported.
Integration tests have no standard format and many deployments are combinations of artifacts built from multiple repositories, and configuration is not standardized (configmaps or ENVs? Both? External source of feature flags?) so all integration tests are manual work.
Metrics and SLOs are manual work; only humans can decide what actual properties of the system are meaningful to measure for the overall health of the system beyond simply readiness/liveness checks. Without key metrics automatic rollouts are fragile. This also means autoscaling isn't truly automatic; you need quality load metrics to scale properly. Not all services are CPU or RAM limited, and sometimes the limit varies depending on traffic.
All that said, cloud functions (Google, AWS, or other versions) are beyond DevOps. If you don't need high-QPS services then use cloud functions. They bypass 90% of the headaches of having code running on https endpoints. Most people don't have high-QPS (10K requests per second per shard) services, and could probably get away with cloud functions (1000 RPS on GCP). Everyone else pays the DevOps or hopefully the SRE tax for now. But we're still trying to automate ourselves out of a job; we don't want to be doing DevOps day-to-day either.