I think Vault by Hashicorp is a great product - I particularly love how you can do dynamic secret generation (e.g for database connections). But how do you validate that the application requesting the secret is allowed to perform that action? How do you know it’s not someone or something impersonating your application? While musing this at an airport the other day, my colleague Patrik sent me a link to a StackOverflow post about this very question...
One of the points I made in my recent NDC talk on 12 Factor microservices, was that you shouldn’t be storing sensitive data, such as API keys, usernames, passwords etc. in the environment variables. Don’t Store Sensitive Data in the Environment My reasoning is that when you were accessing Environment Variables in Heroku’s platform, you were actually accessing some (probably) secure key-value store, rather than actual environment variables. While you can use something like Consul’s key-value store for this, it’s not much better as it still stores all the values in plaintext, and has no auditing or logging....
One of the downsides to microservices I have found is that I end up repeating the same blocks of code over and over for each service. Not only that, but the project setup is repetitive, as all the services use the Single Project Service and Console method. What do we do in every service? Initialise Serilog. Add a Serilog sink to ElasticSearch for Kibana (but only in non-local config.) Hook/Unhook the AppDomain....
This is a follow up post after seeing Michal Franc’s NDC talk on migrating from Monolithic architectures. One point raised was that Database Integration points are a terrible idea - and I wholeheartedly agree. However, there can be a number of situations where a Database Integration is the best or only way to achieve the end goal. This can be either technical; say a tool does not support API querying (looking at you SSRS), or cultural; the other team either don’t have the willingness, time, or power to learn how to query an API....
Last time we went through creating a Dockerfile for a microservice, with the service being compiled on creation of the container image, using xbuild. However we might not want to compile the application to create the container image, and use an existing version (e.g. one created by a build server.) Our original Dockerfile was this: FROM mono:3.10-onbuild RUN apt-get update && apt-get install mono-4.0-service -y CMD [ "mono-service", "./MicroServiceDemo.exe", "--no-daemon" ] EXPOSE 12345 We only need to make a few modifications to use a pre-compiled application:...
Getting a service running under Docker is fairly straight forward once you have all the working parts together. I have an app written (following my guide on service and console in one), which uses Owin to serve a web page as a demo: install-package Microsoft.Owin.SelfHost public partial class Service : ServiceBase { //see the service console post for the rest of this protected override void OnStart(string[] args) { _app = WebApp....
I have found that when developing MicroServices, I often want to run them from within Visual Studio, or just as a console application, and not have to bother with the hassle of installing as windows services. In the past I have seen this achieved by creating a Class Library project with all the actual implementation inside it, and then both a Console Application and Windows Service project referencing the library and doing nothing other than calling a ....