DevOpsDays Houston was a two-day inaugural conference focused on DevOps. It had industry leading sponsors such as Datadog, Microsoft, and Chef.
DevOpsDays Houston was a two-day inaugural conference focused on DevOps. It had industry leading sponsors such as Datadog, Microsoft, and Chef. The main take away and the focus of the conference can be summed up with the short phrase: devops is a process. Oh, and they had a great reception.
It was fun, engaging, and informative. Some of the talks were about specific tools like Kubernetes and some where about things like costs in the cloud, the majority of the talks though focused on the process of devops: devops’ role in the enterprise to create scripted repeatable deployments of things.
Here are my takeaways and how I think they relate to us.
Kubernetes pods are meant to be stateless and can be restarted and moved at any time. This would be a disaster for a database pod that could be in the middle of writing to its data stores. Speaking of that, shared volume performance is hard to guarantee and that can cause latency to the data stores. This was agreed by presenters from Datadog, Microsoft, and IBM. So we may not want to put databases in kubernetes.
As long as nodes get security updates, they should not need to be rotated. They can be, but do not need to be.
Great idea, product teams are a cross discipline group capable of building and iterating over their product. They should own their product and should not have outside responsibilities. Smaller more agile teams where members can wear multiple hats. They would be responsible for guiding the product and deploying it using their tools of choice.
I asked the speaker how we can make that work with a core platform and some semblance of order in choice of tooling without slowing down team velocity and I did not get an answer. I tried to host an open talk to discuss, but not enough interest.
DevOps practitioners should strive to remove roadblocks from engineers and product teams by simplifying the process of getting apps to production. SRE, or Site Reliability Engineers, are DevOps practitioners.
I agree with this, since we touch everything that goes out and provide tooling to others, it is a great interaction point. Users’ (developers) and product owner’s experience can be shaped either very positively or very negatively so it is crucial to get it right.
Since money is finite and we should know what it costs to put our applications online and what the cost difference of specific changes. Makes sense.
A stanford-startx company
an MIT stex25 company
© 2022 ARUNDO - All rights reserved
