Category Archives: microservices

tc

TeamCity : pin and tag a build using the REST API from inside the script

We use Teamcity for most of automation in building/testing/deploying golang microservices to prod and during test phase I wanted to be able to notice easily if an integration/benchmark test crashed a microservice. Pinning the build and tagging it with the word “panic” seemed to be a good idea, from inside the buildconf script :

# txt are are the microservice logfiles, substitute as neeeded
grep panic.go *.txt
retVal=$?
if [ $retVal -eq 0 ]; then
   # grep found panic in some file, tag with panic
   nohup sh -c 'sleep 10 ; curl --header "Origin: https://<your_tc_server>" --header "Authorization: Bearer <yourbearertoken>" --request POST "%teamcity.serverUrl%/app/rest/builds/id:%teamcity.build.id%/tags/" --data panic --header "Content-type: text/plain"' &
   nohup sh -c 'sleep 10 ; curl --header "Origin: https://<your_tc_server>" --header "Authorization: Bearer <yourbearertoken>" --request PUT "%teamcity.serverUrl%/app/rest/builds/id:%teamcity.build.id%/pin/"' &
fi

Took more than expected to figure out this : some examples would be helpful. Note that the build needs to be finished to be able to pin it/tag it so we have to put this ugly sleep to postpone operations on the rest api when the build is finished.

grigna

On the importance of design in software

Many time we face situation were productivity of a software team is impaired by initial flaws in system design. These initial flaws require too much time to be completely removed (the effort of complete rewrite is only marginally touched here and is normally and indication of other problems in your software project )

So, in order for a software team to be able to work at its maximum, good design is a must. Design is much more responsible for productivity than any single coder, scrum master, product manager or development methodology/language in the sense that bad design can take an all-star team using top tools/methodology to perform badly.

There were times when it was taken for granted that before building a system, it was necessary to design it. That time looks gone (even though Agile does not explicitly prohibit making good design). The general idea seems to be that there is “never enough time to do something right, but there’s always enough time to do it over” again.

But what is design in software ?

That kind of intellectual activity which creates a whole from its diverse parts may be called the design of a system

Melvin E. Conway, How Do Committees Invent?

So you compose parts to make the whole system. How you do this ?

It is basically decomposition to generate single parts that acting together will generate the goal. The 2 tools you will need as a designer are :

  • decomposition
  • composition

 But first of all you need :

  • understanding of the system boundaries : the borders of the nation your system lives in
  • understanding the global scenario of what your system is going to do. Designing subsystems without knowing the whole picture is not a good idea.

Why decomposition of a system into smaller components (services) is good for you :

  • information hiding : well identified interfaces create a contract that the component has to provide, hiding any network/system implementation details. This will make the component implementation completely free to be modified/enhanced as long as the new implementation is compliant with the contract.
  • less development time : separate components/services can be developed in parallel since they don’t require (or require little) external dependencies, so less contention between engineers. Every component is independent on integration and performance test that can be developed autonomously.
  • scalability : with little effort in design every component might be deployed in a way to be one of many instances that will make that service scalable when traffic increases.
  • clarity : the system could be studied a component (service) at a time with the result that the whole system could be better designed because it was better understood

We could go on here and analyze what are the criteria to be used in decomposing a system into services. I’ll leave this to another moment and you can find some interesting notes here :

https://blog.acolyer.org/2016/09/05/on-the-criteria-to-be-used-in-decomposing-systems-into-modules/

What I would like to stress is that design is a fundamental phase in software engineering. You can’t just skip it and pretend that since you have a good team you’ll get a good job done.

Thanks to the following for inspiring me on this post :

https://en.wikipedia.org/wiki/Melvin_Conway

https://blog.acolyer.org/2019/12/13/how-do-committees-invent/

https://blog.acolyer.org/2016/09/05/on-the-criteria-to-be-used-in-decomposing-systems-into-modules/

golang-console

Profiling a golang REST API server

Profiling :

is a form of dynamic program analysis that measures, for example, the space (memory) or time complexity of a program, the usage of particular instructions, or the frequency and duration of function calls. Most commonly, profiling information serves to aid program optimization.

How can you profile your golang REST API server in a super simple way :

First : add some lines to your server code

import _ "net/http/pprof"

And then add a listener (I normally use a command line flag to trigger this) :

go func() {
http.ListenAndServe("localhost:6000", nil)
}()

Start your server and generate some load. While your code is running under the load you generated extract the profiler data :

go tool pprof http://localhost:6000/debug/pprof/profile
Fetching profile over HTTP from http://localhost:6000/debug/pprof/profile
Saved profile in /home/paul/pprof/pprof.wm-server.samples.cpu.008.pb.gz
File: wm-server
Build ID: c806572b51954da99ceb779f6d7eee3600eae0fb
Type: cpu
Time: Dec 19, 2018 at 1:41pm (CET)
Duration: 30.13s, Total samples = 17.35s (57.58%)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof)

You have many commands at this point but what I prefer to do, having used kcachegrind for years, is to fire it up using the kcachegrind command :

(pprof) kcachegrind

This will generate a callgrind formatted file and run kcachegrind on it to let you do all the usual analysis that you’re probably already used to do (call graph, callers, callees ..)

Microservices technology map

Microservices basic tools/technology quick guide (will always be work in progress)