6 ms·
Sure. None of the things you mentioned are DevOps. DevOps is two things: 1. Applying the methods of modern software development (version control, automation,
by dsr_ 7y ago
Sure. None of the things you mentioned are DevOps.
DevOps is two things:
1. Applying the methods of modern software development (version control, automation, DSLs...) to operations (provisioning, config, deployment, monitoring, backups...).
2. Reducing silo barriers between devs and ops groups so that everyone is working together as a team, rather than blaming each other for poor communication and the resulting messes.
Then there are all the DevOps hijacking attempts, such as equating it to Agile or Scrum or XP, or insisting that it's a way to stop paying for expensive operations experts by making devs do it, or a way to stop paying for expensive devs by making ops do it, or a way to stop paying for expensive hardware by paying Amazon/Google/$CLOUD to do it.
No matter what your software-as-a-service company actually does, it will need to execute certain things:
- have computers to run software
- have computers to develop software
- have computers to run infrastructure support
You can outsource various aspects of these things to different degrees. Anywhere you need computers, you have a choice of buying computers (and figuring out where to put them and how to run them and maintain them), or leasing computers (just a financing distinction), or renting existing computers (dedicated machines at a datacenter) or renting time on someone else's infrastructure. If you rent time, you can do so via virtual machines (which pretend to be whole servers) or containers (which pretend to be application deployments) or "serverless", which is actually a small auto-scaled container.
Docker is a management scheme for containers. VMWare provides management schemes for virtual machines. Kubernetes is an extensive management scheme for virtual machines or containers.
A continuous integration tool is, essentially, a program that notes that you have committed changes to your version control system and tries to build the resulting program. A continuous deployment system takes the CI's program and tries to put it into production (or, if you're sensible, into a QA deployment first).
- movedx 7y agoAt last, someone who gets it. Absolutely nailed it. Great answer. I never log into my HN account anymore, but for this response I just had to say: yes. Well said. When you boil the Cloud, DevOps, CloudOps, SecOps, *Ops, CI, CD, Containers, VMs, and all the other technologies we've devised over the past ten years, you always end up at the basic building blocks. You eventually come to the conclusion that all we're really doing with all these new tools is adding software layers on top of those building blocks in an attempt to make them easier and faster to consume. And how have we done overall? Not bad, if you ask me. Some solutions are overkill for most people (K8s is an example of over kill for a start up and even an SME.) But Terraform, Ansible and GitLab (CI) are something I'm currently developing a highly opinionated video training course on because I believe they strike the right balance of improving on prior experiences without taking the absolute piss.
- heurisko 7y agoI am a developer, who also dealt with ops in a small business context. I agree with Ansible striking a good balance between prior experience and the future of automating server configuration. I did a write-up on how I used it on my blog: https://heuristicservices.co.uk/2019/08/13/staging-and-production-servers-with-vagrant-and-ansible/ https://heuristicservices.co.uk/2019/08/13/staging-and-produ... The workflow worked really well, provisioning Vagrant servers in staging and Digital Ocean droplets in production.
- movedx 7y agoNice write up. Good job, mate. I moved away from Vagrant in favour of Terraform, but I agree Vagrant still holds its own and is a great choice (HashiCorp really nailed it, eh?)
- GordonS 7y agoThanks, I appreciated this blog post - I've struggled to get started with Ansible before, and this was just what I needed!
- high_5 7y agoI agree with _dsr, he really nailed it. As for GitLab I agree they got the balance right except that it feels quite Kubernetes centric.
- cpb 7y agoThere is a lot of flexibility in the CI/CD configuration. You don't need to use the Kubernetes stuff.
- vageli 7y agoCurious about where you see ansible fit in while using Terraform, could you expand on that? Everywhere I have thought I would need ansible to scratch an itch it has turned out that terraform has that functionality in some way (through null_resource, runners).
- peterwwillis 7y agoJust some minor clarifications: - DevOps is a peer with Agile and Lean. Scrum and XP are Agile implementations. Scrum doesn't prescribe ways to code, XP does. - 90% of what people develop or run today should be in containers, and not because containers are great, but because of the DevOps patterns of IaC, immutability, reproducibility, homogeneous environments. Whether you run them on your laptop, a VPC, AWS Fargate, a K8s cluster, etc is dependent on your business needs. - Continuous Integration and Continuous Delivery aren't so much tools as a practice, and they're more complicated to implement at scale than just using a tool. There are some great books on the subject.
- dsr_ 7y agoPlease do me the favor of engaging with what I wrote.
- peterwwillis 7y agoI thought I did? Also, this feels a bit passive-aggressive, did I do something wrong?
- dsr_ 7y agoIt was meant to be polite. Under the guise of "clarifying" what I said, you completely contradicted it, without even doing me the courtesy of addressing my statements directly. If it helps, my core point is: DevOps is the name we give to two philosophical ideas. The first idea is that the tools and methods of software development can be used to improve our ability to do operations work. The second idea is that siloing people with operational skill away from people with development skill is a terrible practice. Along the way, I specifically denounced the idea that DevOps is a single methodology, or that some tools are more DevOps than others, or that DevOps makes prescriptions about what you should do. Those are all things that you immediately advocated.
- peterwwillis 7y agoI wasn't sure how much your ideas deviated from mine, which I why I said "clarifications"; but you're slightly incorrect. DevOps isn't two philosophical ideas. It's lots of things, and all those things are the methodology. There are many books, podcasts, blogs, conferences, etc that go over all of the things DevOps is. It actually has little to do with tools or software, even though that's basically what it was created around. It is a general methodology, and you pick how you implement it. You can even apply DevOps to non-software processes. Look at it this way: The Toyota Production System isn't about cars. It was developed specifically to produce cars as well as they could be, but it doesn't address "car problems"; it addresses business problems, production problems, workflow problems. It applies methods as practices in ways that are specific to the production of cars, but you can apply the principles of TPS to things other than building cars (as we do with Lean). DevOps is comparable to TPS (well, Lean), but for software instead of cars, and it borrows from other systems, and it has a few of its own ideas specific to software. > Along the way, I specifically denounced the idea that DevOps is a single methodology, or that some tools are more DevOps than others, or that DevOps makes prescriptions about what you should do. Those are all things that you immediately advocated. I advocated using containers because they help reinforce DevOps principles better than alternatives. You don't have to use them, but that doesn't make them un-applicable to DevOps. There are different levels to DevOps, and one of them is "practices": particular ways of doing things that DevOps encourages, such as Infrastructure as Code, Immutable Infrastructure, Heterogeneous Environments, Continuous Integration & Delivery, etc. Things that containers are more useful at accomplishing than, for example, VMs. You don't have to use Kanban to run a car production line. But it's more TPS than the alternatives.
- lioeters 7y agoI wish I could upvote this multiple times. Thanks for sharing your knowledge!