Month: August 2020

Microservices and deployment best practices

h.eskandari on

As stated in the previous post, a side effect of designing a system using microservices is that you end up having tens and hundreds of services that you need to keep running. One challenge right there, especially when it comes down to critical systems with zero down-time policy, is that how do you ensure these microservices are operational?

Fortunately, the software development community has already established patterns such as Continuous Development, Continuous Delivery, Canary releases and Blue/Green deployment methods (Kargar & Hanifizade, 2018). Yet, there are two concerns:

  • Does your organization already have these practices in place? There is a learning curve and organizational acceptance that takes time to establish these patterns. If these are not already well established, it is suggested that you start there first.
  • Even when you already have these practices at your organisation level, how do you ensure the release has the required quality before you deploy it?

There are other challenges related to how microservices are deployed and are run, which is the subject of the next post.

References
Kargar, M. J., & Hanifizade, A. (2018, 25-26 April 2018). Automation of regression test in microservice architecture. 2018 4th International Conference on Web Research (ICWR)

Monitoring in Microservices

h.eskandari on

One thing that is fundamentally different when comparing a legacy and traditional architecture to a distributed system such as Microservices or SoA is that due to the nature of more things being run in parallel, it is just hard to make sense of things. In fact, the move to write multi-threaded applications become more comment with the advent of multi-core CPUs in the last decade as a way to better use the system resources and to write a more performant software. While performance gains are great, running multi-threaded softwares comes with a caveat: it is harder to monitor, trace, debug and make sense of things.

There is yet another problem with monitoring when it comes to microservices. Traditionally the monoliths would have a set amount of executables and services that needs to be monitored. Even in terms of scaling, they only scale vertically, which means they run on a bigger machine and that doesn’t change the way things are monitored, which is having an eye on one machine that has everything (hence the word monolith). In microservices however, a decomposition of a software system may result to hundreds of micro service (Cinque et al, 2019) and each could be deployed to a separate box and scaled horizontally (e.g. run on multiple machines). So just by doing this, now you have tens if not hundreds of machines (whether virtual or physical) that you need to keep an eye on.

References

Cinque, M., Corte, R. D., & Pecchia, A. (2019, 27-30 Oct. 2019). Advancing Monitoring in Microservices Systems. 2019 IEEE International Symposium on Software Reliability Engineering Workshops (ISSREW)

Research methodology

h.eskandari on

To create the assessment artefacts, had to lean about research methodologies and how to write up a research proposal. A subject that is not only completely new, but has to be done by the deadline. To top that off, Computer Science – unlike technology related topics – does not seem to have that many resources to teach you how the research should be done in this field.

While reading up on the subject, I found an article that might be useful. Dodig-Crnkovic (2002), quoting Dijkstra, mentions that computer science departments, have, under external pressures, underemphasized the “science” aspects of the knowledge area in favor of “computer” that is a tool not a science. It further goes on saying how ridiculous this would sound if this was done in other fields. For example, a knife is the tool that the doctor uses for the surgery, but the surgery is not called “Knife Science”. If you are interested in this topic, you can read up on the article “Research Methods in Computer Science: The Challenges and Issues”.

Quantitative vs Qualitative methods

What are the differences? Is should be clear from the name: Quantitative research method focuses on the numbers. The tools involved is statistical or numerical analysis and you need to specify where the data comes from, how it is collected and analysed. The Qualitative research on the other hand does not focus so much on the pure numbers. With this method you can focus on what you think and why you think so.

 

Focusing on the Business Capability

h.eskandari on

Often times, specially around developers, the discussions around Microservices is goes around the underlying technology: “I have a [technology related] microservices that…” where the technology is usually the leading / bleeding edge of the technology that makes developers excited about their code. This, in fact, is the wrong perspective on looking at things, since the cornerstone of Microservice is the business capability.

We need to keep in mind that the code, the architecture and the ultimate software is there to address a business need. The fact that we are using one architecture style or the other makes no difference.

So what is a business capability? “A business capability is a concept from business architecture modeling. It is something that a business does in order to generate value.” (Richardson, 2018)

This also means that having a component run in a docker container, cloud edge or a Kubernetes cluster, it does not automatically become a microservice as it violates what in my opinion is the most important rule of the design. After all, your business does not generate a value by running, as an example, docker containers, unless that is the core of your business.

 

Citations

Richardson, C. (2018). Microservice Patterns (1st ed.). Manning Publications.