Teamcity free disk space requirement - Free disk space requirement of 3 GB could not be met for directory /opt/JetBrains/TeamCity - TeamCity Out of Space

By default TeamCity has 3 GB space for build. If you have smaller instance, you can change it to reduce.

Open buildAgent configuration file by executing below command:
sudo vi /opt/JetBrains/TeamCity/buildAgent/conf/buildAgent.properties

add below line
system.teamcity.agent.ensure.free.space = 2gb

save the file

Now restart the build agent
/opt/JetBrains/TeamCity/buildAgent/bin/agent.sh stop

/opt/JetBrains/TeamCity/buildAgent/bin/agent.sh start


Click here to see steps for installing TeamCity on Ubuntu

Microservices Introduction - How to re-factor your existing monolith into microservices architecture?

You are brewing your morning Coffee at your work and you are hearing words such as DevOps, CI/CD, Microservices, Docker.. well, you are not alone..Most of the companies are at least trying to start microservices for a new development..or they are thinking to migrate from existing monoliths. Before we deep dive into that topic, let's try to understand what is monolith(traditional web/ear) application. Monolith is usually a single large web app which has everything built-in. A small code change in UI requires a build, deployment and test, even you did not modify code in business or data layer. Also, if you would like to scale out a particular layer, it is difficult as it requires a deployment of whole WAR on new instances. Here comes the Microservices to solve some of the issues.

What is microservices?

Breaking a large application into a set of simple services, also called as functional decomposition.

Each services can be independently developed and deployed

Modular approach to system-building

Each service have its own persistent storage

Microservices  are independent in code, technology,  scaling.

Architecture difference between Monolith and Microservices

Microservices is an architectural approach of breaking application (functional decomposition) into smaller services where each service can be independently developed, deployed with no limitation to technology stack. Yes. It can be scaled out without impacting other services. 

But trickier question is when should I use use microservices? Answer is it depends..If you are developing a large or complex application from scratch, start with microservices architecture by separating UI, business and data layers. If you already have a large app deployed to production which becomes a hard mountain to climb, you can address this problem in this way.

How to re-factor your existing monolith into microservices architecture?

1. Implement any new functionality as microservice. 
2. Split the presentation components from the business and data layer.
3. Incrementally refactor your application into a set of microservices without fully decommissioning the monolith app.
4. Re-factor your monolith incrementally.

Here are some of the best but simple practices to consider when developing microservices.

Best practices on developing Microservices

1. Design for failure(fault tolerance)
2. Use one repository per service
3. Each service should have independent CI/CD pipeline
4. Each service should be loosly coupled
5. Incrementally refactor your application into set of microservices when migrating from monolith
6. Create a separate data store for each microservice.
7. Deploy microservices in containers(docker)

There are few drawbacks too when implementing them.

Drawbacks of Microservices

1. Developing distributed system can be complex.
2. Multiple databases and transaction management can be painful.
3. Testing Microservices based application can be cumbersome.
4. Deploying Microservices can be complex as it requires co-ordination among multiple services

Azure cli command to create resource group

az group create --name myResourceGroup --location eastus