There's an interesting trend of expanding the range of work products developers produce as the outcomes of their work. In software development prehistory it was just functional code (one that's supposed to provide business value directly). After some time automated tests have joined it - as a parallel code construct, meant to be submitted within the same commit. That was just a beginning, as the same has happened to (among others): data schema modifications (DDLs & equivalents) deployment routines (automated provisioning, configuration mgmt, etc.) infrastructure setup (infrastructure-as-code) All of these are now key code constructs (as important as functional code…
All posts in DevOps
Docker is The Thing these days. Pretty much everyone has heard about it - how lean, lightweight & useful it is. Most likely you have seen the eye-catchy logo, went through very approachable tutorial, watched some basic demos. But did you try to look through the hype to verify whether it can be actually useful for you? No? Here's your opportunity, let's break some myths & look for actual value. Obvious stuff is ... obvious I expect you to know the basic marketing about Docker: it is "the virtualization 2.0" - significantly reduces the overhead on each "…
There are no two dev machines that are completely alike: same software installed (& uninstalled) in the same order, same security patches applies, same OS settings, same IDE configuration. And that's great of course - developers are expected (hopefully in your company as well) to: search for new "toys" - tools / libraries / add-ons / anything that could aid their work & improve their productivity learn new stuff that's somehow related to their projects as it may end up totally applicable in their work quickly switch between projects that require absolutely different sets of tools & machine setup You can…
Setting your applications may get really messy - especially on Linux: different applications have different configuration approaches, they keep their binaries & data in different file-system locations (these differ because apps may have origins within varying Linux distributions). Once you set things up once, it's pretty hard to restore the previous state, especially if you've made some other changes in the meantime (for instance - installed something else). That's why provisioning tools like Puppet, Chef, Ansible or Salt got that much popularity recently - but even with them, creating the cookbooks / recipes may still be very challenging: Linux is famous…
Straight to business - I've participated in a very interesting discussion about development architecture recently: which scenario works better & brings more benefit to the organization: each team is responsible for all their deployment / maintenance mechanisms separately (let's call it Scenario A) there's a dedicated DevOps ('Development Architecture') team that is responsible for deployment / maintenance mechanisms (they provide them for other teams) - for the sake of clarity, it will be Scenario B Both solutions have their PROs: In Scenario A: there are minimal external dependencies x-functional team is able to do all their work on their own if their…
Dealing with technical configuration of your apps may be tricky. In a simple case you just slap a text file or two and there's no harm done, but once your solution gets more & more complex, all those pesky files get really cumbersone: keeping the content of them all in sync modifying the large number of them (usually remotely) in virtually the very same moment preparing the dedicated version for every machine (in distributed scenarios) etc. Obviously, manual configuration adjustments should be prohibited - I've already written a blog post or two about that in the past. BUT even if…
All the considerations below are based on DevOps <-> Dev scenario, but IMHO vast majority of them applies well to any supplier <-> buyer scenario. DevOps' reality is somehow simple: they work for other developers (their "clients") their goal is to make other developers focus solely on the business functionality, without caring much about setting up the development process or deplyment pipeline itself automating what could be automated (so other developers have as few tedious and repetitive tasks as possible) setting the standards & convententions that would keep the tech debt under control / security…
This is part III of coupling consideration topic. If you want to check my past coupling-related posts, you can find them here: Part I - the theory of coupling Part II - practical examples of coupling and how does it really affect your apps (& services!) Now it's time for Part III - let's bring up some ideas about how to fight the coupling off. To make things more spicey, let's start with the most tricky one - the run-time coupling. What do want to achieve? We want to make sure that: Disruption of one service has a minimal impact…