Service Creation Overhead

At work we started spinning up a new service and concerns were expressed by some interested parties about the overhead required to get a new service into production. Among the specific concerns that were articulated: it needed to have a repo made, CI builds set up, be configured for the various environments, be creating databases in those environments, etc. Having not deployed a new service at this job I’m not sure if the concerns are overblown or not.

We’ve got a platform set up to help speed the creation of new microservices. The platform can help spin up CI jobs and simplify environment configuration. Creating the repo should be a couple of clicks to create it and assign the right permissions then set up the hook for the CI process. I’m optimistic that this process should make it easy, but only two people on the team were part of spinning up a new service the last time the team did it, and neither of them was involved in much of dealing with this infrastructure.

The project all of this is for needs to be put together and running in production in the next month, so the overhead can’t take up much of the actual schedule. The first version of the service isn’t complicated at all and can probably be cranked out in a week or so of heads-down work. It needs a little bit of front-end work but has been descoped as far as possible to make the timelines easy. We’ve got a couple of code generators to help bootstrap a lot of the infrastructure of the service; we’ve even got a custom yeoman generator to help bootstrap the UI code.

I’m curious if the concerns were memories of spinning up new services in the world that predates a lot of the platform infrastructure we have today or if it’s a reasonable understanding in the complexity of doing all of this. But it raises the question of how much overhead you should have for spinning up a new service. As little as possible seems reasonable, but the amount of effort to automate this setup relative to how often you create new services makes that not as reasonable as it first appears. I think it needs to be easy enough that you create a new service when it makes logical sense in the architecture and the overhead of doing so isn’t considered in the equation.


Cloud Computing Patterns

A colleague recommended this list of application design patterns for cloud computing. The idea of common dictionary of terminology is always important. This is a good collection of the different patterns that can be used in a cloud application. Using the abstract pattern names rather than the specific implementation names can help abstract the discussion from a single implementation to the more generic architectural discussion. A specific implementation can have specific strengths, weaknesses and biases, but a generic pattern is the more pure concept. The concept allows the discussion to focus on the goals rather than implementation specifics at the initial level.

I read through the patterns and found a couple I hadn’t been aware of like timeout-based message processor, community cloud and data abstractor. The timeout-based message processor is a name for a concept I was familiar with, but never had a name for. Essentially it’s a message handling process where you ack the message after processing, as opposed to on receipt. The community cloud is a pattern for sharing resources across multiple applications and organizations. The data abstractor is a way to handle multiple services having eventually consistent data and show a single consistent view of the underlying data, by abstracting the data to hide the inconsistencies. None of these three patterns is a mind blowing solution to a problem I’ve been having, but they’re all interesting tools to have in my toolbox.

There are a bunch of different ideas which vary from the common base level knowledge of cloud computing to solutions for some quite specific problems. The definitions of the various patterns are concise and reference other related patterns, so even if you don’t know exactly what you are looking for you should be able to find your way to it fairly quickly. Overall worth checking out if you are working on a distributed application.

Automation and the Definition of Done

I recently listened to this episode of Hanselminutes about including test automation in the definition of done. This reminded me of acceptance test driven development (ATDD) where you define the acceptance criteria as a test which you build software to fix. These are both ways to try to roll the creation of high level automated tests into the normal software creation workflow. I’ve always been a fan of doing more further up the test pyramid but never had significant success with it.

The issue I ran into the time I attempted to do ATDD was that the people who were writing the stories weren’t able to define the tests. We tried using gherkin syntax but kept getting into ambiguous states where terms were being used inconsistently or the intention was missing in the tests. I think if we had continued to do it past the ~3 months we tried it, we would have gotten our terminology consistent and gotten more experience at it.

At a different job we used gherkin syntax written by the test team; they enjoyed it but produced some significantly detailed tests that were difficult to keep up-to-date with changing requirements. The suite was eventually scrapped as they were making it hard to change the system due to the number of test cases that needed to be updated and the way that they were (in my opinion) overly specific.

I don’t think either of these experience say that the idea isn’t the right thing to do, just that the execution is difficult. At my current job we’ve been trying to backfill some API and UI level tests. The intention is to eventually roll this into the normal workflow;  I’m not sure how that transition will go, but gaining experience with the related technologies ahead of time seems like a good place to get started. We’ve been writing the tests using the Robot Framework for the API tests and Selenium for the UI ones. The two efforts are being led by different portions of the organization, and so far the UI tests seem to be having more success but neither has provided much value yet as they have been filling in over portions of the application that are more stable. Neither effort is far enough along to help regress the application more efficiently yet, but the gains will hopefully be significant.

Like a lot of changes in a software engineering the change is more social than technical. We need to integrate the change into the workflow, learn to use new tools and frameworks, or unify terminology. The question of which to do keeps coming up but the execution has been lacking in several attempts I’ve seen. I don’t think it’s harder than other social changes I’ve seen adopted, such as an agile transition, but I do think it’s easier to give up on since it isn’t necessary to have high level automated testing.

Including automation in the definition of done is a different way to describe the problem of keeping the automation up to date. I think saying it’s a whole team responsibility to ensure the automation gets created and is kept up to date makes it harder to back out later. The issue of getting over the hump of the missing automation is still there, but backfilling as you make changes to an application rather than all upfront may work well.

2016 Year in Review

Looking back at this year’s blogging, strictly by the numbers everything is much bigger than last year. Last year there were 63 pageviews by 42 visitors, this year there were 440 views by 359 visitors. Part of the increase was since I have a whole year rather than a couple of months’ worth but that doesn’t account for the whole increase.

Last year I outlined some goals for this year.

  • Increase readership
  • Keep up the weekly posts
  • Write more technical posts
  • Write about what I was doing at work some

I feel like I achieved each of these goals. The views were up considerably, for both the new posts and some of the old posts. I hit the weekly post goal, although I went through a good bit of the backlog of post ideas I had. I got some more technical posts with some of the Nuget conversion, Scala posts and the anonymous type serialization. The Nuget conversion was what I was doing at work and I got to talk about that some.

As for some of the specifics of this year, F# Koans and the post on the Javascript Ecosystem both continued to get a good number of views. The post on Modern Agile was a surprise hit on my part racking up 108 views and a surprising variety of incoming sources from LinkedIn, Slack, and a couple of different tweets.

I’ve got a couple of goals going forward for 2017

  • Continued increases in readership
  • Keep up the weekly post cadence
  • Write a longform piece and see what that looks like in this format

I don’t have any specific means to accomplish the readership increase. Last year I added references to the blog in a couple of profiles I had other places, but that seems to have only generated five referrals. Since a quarter of the views came from one post I’m slightly concerned that readership may go down. The weekly post cadence helps me keep in the writing habit and while there have been some posts that didn’t generate any views, that’s something I think I can live with. I’d like to try the longform piece since a number of the posts I’ve been writing are just pointing towards other people’s ideas and not a lot of new thoughts. To a certain point the problems I’m fighting and the solutions I’m deploying aren’t that different than what other people are doing so a lot of these ideas are already out there in the world.