I’ve been doing the devops thing for as long as I can remember. It’s always been a part of the job. Now as I contemplate the new landscape of micro services and it’s impact on the teams, business and the clients I’m starting to think about where the value comes from.Just about 7 years ago I designed and built a POS terminal. It included all of the usual peripherals which were connected via USB. And while micro services were not popular at the time the complexity of identifying and connecting to each different device meant it was well suited for micro services. But the one thing that made this design successful was that each service was built in it’s own identical pipeline. That the build pipeline was identical was probably the single most important detail.Now as teams are moving from monolithic applications to micro services they are also looking at custom build pipelines per project. While CIs like Jenkins, Travis, and Drone offset this by putting the build details in the project source the only way to easily refactor back and forth with the pendulum is if that configuration is as similar as possible.Microservices are a great way to separate concerns, deliver working software, and provide loose coupling. Taking a note from Apcera I also like the BUS or message queue as a way to implement policy. This strategy only works if there is discipline in the build and an underlying services framework.