ered from development , they ’ re done with it and another team typically takes over the maintenance and support of the application . When delivering a service , development is never done as long as that service is being consumed by customers . At a Puppet conference two years back , Mike Stahnke of Puppet delivered this classic quote about developing services : “ you are never done until your last user is dead .”
Focusing on the technology alone and ignoring the political and social aspects of this change is a recipe for disaster .
With services , the days of throwing code over the wall to be someone else ’ s problem are over . The developers need to autonomously manage and maintain their services , which means they need application performance monitoring ( APM ) and logging tools to get fast feedback and alerts . Monitoring becomes more of a proactive , as opposed to a reactive , practice . Since many different applications and users may rely on it , the service must always be up . Operations teams still watch over the infrastructure , but developers watch over their services .
This new approach radically changes the silo based operating models of the past and requires closer collaboration between developers and operations . Team structures align to products and services with small teams that include a broad spectrum of domain expertise and skillsets . Functional silos don ’ t work well in a service oriented world .
Vertical vs . Horizontal Architectures
Traditional vertical architectures are made up of two or three tiers ( web , app , database ), and capacity planning is required in order to allocate enough compute and storage resources to adequately scale . Scaling vertically means adding additional hardware or hardware components to the existing infrastructure . This task is performed by hardware experts . Applications are built with the expectation that the hardware will always be there , and an army of people are charged with making sure that assumption is a reality .
SUMMER 2016 | THE DOPPLER | 71