TQ
dev.com
Blog about software development
27 Apr 2017 - by 'Maurits van der Schee'
If you are currently developing a monolithic ASP.net legacy system you are probably dreaming about migrating all functionality step-by-step to a modern micro-service design with cheap Linux servers running Go. If you aren't, then you should! But in order to do this super-stealth (without your boss finding out) you need to do this one API call at a time. Sounds easy.. if only... you were able to read ASP.net's proprietary encrypted (secure) cookies. Well, I've got good news for you: Now you can!
I created "aspnetcookie" a Go implementation of ASP.net's (now open sourced) FormsAuthentication. Tell your boss you need to switch your ASP.net application to FormsAuthentication with SHA1 AES encryption in your Web.config file (you could argue that that is needed for security and scalability reasons) and you are good to go. In order to ensure that you can migrate specific API calls per release you need to put a "Layer 7 (Application) Load Balancer" like "Amazon ALB", "HAProxy" or even just "Nginx" in front of your webserver. You may argue that those are better at "SSL offloading" than your expensive Windows boxes.
Go runs faster and is better at parallel execution than .net. It also compiles to executables that can be easily shipped to the target computer as they can easily be cross-compiled and contain all dependencies. It is designed by the people behind C and they tried to take all the good parts of C and combined them with all the good parts in more modern languages; I feel they succeeded. It compiles super fast and does so on any platform. It really is the ideal language for micro services.
I wanted to make this pretty, so for this Go project I have set up continuous integration and coverage registration using TravisCI and Coverall. It allows you to see whether or not the unit or functional tests succeed or fail on every commit. It also registers the percentage of coverage that the code has. Both services are free for open-source projects. Check out the links. Awesome isn't it?
It is very important to immediately know whether or not a commit has broken a test. I feel that automated tests almost always pay off. Not (only) because they save on testing time, but also because they make you reconsider every line of code and allow you to refactor (and do other software maintenance) with less risk. It is also important to see which lines are not covered with tests yet. This allows you to ensure that your tests are "complete" or not.
PS: Liked this article? Please share it on Facebook, Twitter or LinkedIn.
Subscribe