loading...

What language for a corporate transition?

sirhaswell profile image Rayan Desfossez ・1 min read

I join a new company, it has api in C# ASP.NET and hosts it on Windows server!
He would like to switch to another cross platform solution and convert their monolithic api into a microservices api.
I am the only developer in the company (200/500 employees)

What technology do you recommend and why? (I've heard about asp.net core but I find it quite complex compared to AdonisJS, Laravel, Rails)

Discussion

markdown guide
 

I'm a fan of F# and plain functional programming myself. We use that and deploy docker images to linux servers. I agree that the Kestrel API could be a little less weird. But the settings are documented and work. I don't tend to use the default MVC stuff though. I hate attribute-based approaches because it is so opaque and hard to trace in code. I use more functional libs for the back-end API (see Giraffe) and JS front-ends (Elmish).

I would be very wary of a transition to microservices with only a single developer. (see Conway's Law.) It will add a lot of new problems around service communication and coordination. If you had multiple teams, you would face those same kind of issues across teams so those would need solving anyway. But with one developer, it's extra work for little benefit. You would probably be better off modularizing the existing app. I am not saying to only use a single service. But be wary of lots of single-responsibility micro-services in that org structure.

 

I'll think about it for the micro services! Thank you for your F# advice, I haven't heard much about it, so I'm going to find out!

If others want to make proposals, don't hesitate!

 

I wrote an article on F# here. There are other ways to write functional code, and F# also supports OO. But I find my approach much easier and quite maintainable.

 

The first question you need to answer is "Why?" What is it about C# that's causing problems?

Until you understand the problems you're trying to solve, and you can quantify the cost of not fixing those problems, then making a recommendation is impossible. If you switch "just because" you'll spend years re-writing code that already works, making a derivative, far buggier version, and will have to retrain your team on the new codebase and/or language. It's going to be expensive and ugly, so there better be a good reason.

You can always split up an app like that into smaller components, move to a microservice model, without having to change a lot of code or introduce new bugs. Think of an incremental step-wise iteration towards a goal rather than committing to the silver bullet approach.

 

The problems come from the fact that the application does image calculations, generates pdf's, actually does quite heavy tasks and has latency problems, moreover the backend was managed by student apprentices and so he would prefer to redo the api starting from something more reliable.

The api is not very big and the demand comes from the management, I'm also the only developer so no one else to form

I'm going to redesign the architecture in modules rather than micro services...

 

A good option to pivot to might be Node.js if you're concerned about speed and have a lot of PDF workflow tasks. The async model can take some getting used to, and the code can be tricky to write, but the performance is exceptional and if you're careful to use tools like Mocha and Chai to write lots of tests, you can keep regressions in check.

Consider: Microservices are often just modules that have their own process and resources.

Hope you can get a messaging layer in there like RabbitMQ which makes it easier to monitor how your application performs.

It's also worth looking at examples of observability to see how you might architect with that goal in mind regardless of how you're approaching this.

 

I don't want to dive to much in explanation but you should look at Phoenix and Elixir. ;)

 

Would you mind telling me why?
Elixir has always intrigued me...

 

Elixir in based on the battle-tested Erlang BEAM VM, to explain without entering in to much details. Erlang was developed for the telecoms by Ericsson because the services must be available at near of 100%, Erlang said they obtained 99.99% but it is much more. Erlang has the « let-it crash » philosophy (check on the web). Erlang has hot-code reloading for free, and this is soooo cool. Erlang has a very big and complete library named OTP and you can do what you want with it, you rarely need libraries. Erlang is developed primarily for concurrences, not like Go does, much more better, communication between processes is very easy, managing processes is very easy thanks to supervisor, ...
Erlang has just one bad point, the syntax is really too old and managing projects is more difficult.

Elixir is so based on Erlang and it comes with internal project manager named mix, unit testing framework ex_unit, documentation ex_doc... and it offers quite the same syntax as Ruby.
Elixir is functional and with its pattern matching is so easy to developed. At the first step, you can be lost cause of that but when you finally understand it’s very cool to use Elixir.

For the notable projects, we have Phoenix which is a very good web framework you can do web app, real time app (thanks to live view), api,... Quixir for heavy tests, Quantum to lunch processes with like a Cron table, Phœnix PubSub to easily communicate between processes, to subscribing from message queue, Ecto which is a very good database manager and ORM-like.

And Erlang/Elixir is used by Facebook, WhatsApp, Pinterest, some US governments website, Discord, Slack and much more...

There is so much more things to say, in a finally note, we started using AWS services and because it costs too much we migrate lot of things into ECS with Elixir apps and we finally reduced the billing for the quite same features and for more monthly uses.

 

Microsoft is a great partner (also, Oracle is dreadful), that's not a tiny company (200/500 employees) and they (MS) probably have a product, and expertise, that fits every need you currently have or ever will. I'd guess you have users on a Windows domain so I'd use C#, PostgreSQL, .Net (&.Net Core), Asp.net, React and such, but whatever, all of it except C#/ASP.NET are changeable. ASP.net is really powerful (and reliable). My advise would be 'don't reinvent the wheel' .. or 'keep it simple'

 

Hi, I was talking about my company for the (200/500) employees!
I would like to alert you that this company doesn't like its C# backend anymore and would like to work on a new API that wouldn't have so many bugs anymore!
I just arrived, I can change the stack as well as make a simple transition to .net core but it's true that asp is a bit scary in its size.