Choosing the right technology for your project can be confusing. It often helps to talk to a senior developer – someone with the technical expertise to help you make the best choice.
If you’re considering the .NET framework, Kristiyan Petrov, Senior .NET Software Engineer can help you decide if it’s a good fit for you. In this short conversation, he outlines key insights on launching a project with .NET. And he speaks from experience. Here are some of the main points in the talk. You can watch the video on YouTube.
By loading the video, you agree to YouTube’s privacy policy.
Learn more
Choosing the right tech for your cloud
Every cloud provides different technologies. For example, if you want to use Service Bus, you can use Azure Service Bus or RabbitMQ. But if you’re using Azure Cloud, it’s better to go with their bus, because it’s being maintained by them. It’s better because if you want to use, for example, RabbitMQ, we have to pay for DevOps.
Usually, every cloud provider offers their own alternative for most technologies. If you want to use .NET for your project, it’s better to also use their cloud. With an external technology, you’d also need to pay for support, which is more expensive.
.NET development environments
For the development environment, when we want to create a feature, we initiate SFTP containers. We’re not paying for SFTP in the cloud because this is also a part of the cost optimization – every developer initiates resources when they can. We are using Docker and Docker Compose. We’re managing everything.
The example above is with SFTP because this is what we use in our current project. This methodology can be applied for databases and so on.
.NET 6
In my team, we use the latest .NET 6. We use libraries – some abstractions, boxed in NuGet packages. This is the easiest way to share code between the microservices.
This came with a certain responsibility. If you introduce a breaking change in a Nuget package, it’s going to reflect the others. Also, when you use .NET 6, you have to update most of the packages to that version. So if, for example, you have to use EF, you must use it with version 6. This way you use the latest versions of every technology.
Should we use microservices?
Since microservices are hard to manage, you should make sure you need them. They’re not a one-size-fits-all solution, either. For example, if you have an idea and are just starting a project, it’s not a good idea to start with microservices right off the bat. Instead, maybe start with a monolith application, write it with some design patterns. Then you can easily extract some parts into microservices.
Starting with microservices comes hand in hand with slow development and respectively slow time to market. High cost for every feature, because it’s harder to introduce new ones if they’re communicating with more than one microservice. Microservices mean introducing additional complexity and need for management. They have to be hosted in the cloud – which is, again, expensive. Someone has to set up and support the different environments – DevOps. Again more money.
What should you know before outsourcing
Being aware of your goals and requirements is the most important part.
When we’re building architecture, we need to know what the plan is.
How many microservices are we going to develop?
Are we going to use a Kubernetes cluster or deploy the microservices separately and migrate them later? This one also matters in terms of cost optimization, since Kubernetes isn’t cheap.
What’s your timeline? If you’re planning to start with a small team of 2-3 people, they might not be able to build many microservices for the first few months, because developing libraries is a slow process.
Ultimately, you need to know exactly what you want. Once that’s clear, you communicate with your software development partner. You align expectations, brainstorm, they give you their thoughts and predictions.
When someone wants to be our partner and build an application together, we know that entails a lot of communication at first. Clear requirements and two-sided transparency are key for proper cost and time estimation. We figure out what needs to happen together – that’s the only way to ensure a successful partnership.
