Putting It All Together

Posted on February 15, 2017 by qtzar

Replacing Domino as your application environment is not an easy swap of one product for another. There is no one product that can do everything that Domino can do. Some can get close but nothing can give you every part of the puzzle. To that end here are pieces that we have decided to move forward with.

Backend Code
Java with the Spring Boot framework with an aim towards writing microservice style applications.

Frontend
Thymeleaf Java Templating Engine running inside a Spring Boot based jar file.

Authentication and Authorization
Microsoft Azure AD as the directory store fronted by Auth0 as the Authorization manager integrated with Spring Security on both the backend and frontend.

Source Control
Microsoft Visual Studio Team Services GIT repositories

Issue Tracking / Agile Workflow
Microsoft Visual Studio Team Services

Data Storage
Microsoft Azure SQL Server for relational data.
Microsoft Azure Document DB for noSQL data

Deployment
Microsoft Azure based Virtual Machines running Docker with Rancher as the orchestration and management layer.

Build and Release Management
Microsoft Visual Studio Team Services

I have not talked about Build And Release management yet, I plan to talk quite a bit about how we have that setup to integrate with our deployment system. I have also not recommended any particular IDE because that is a personal choice and does not affect any of the other choices. Personally I prefer IntelliJ, it took a little getting used to after using Eclipse but overall I personally think it is a better product. If you do look at IntelliJ and you are also looking at Spring Boot then you should get the Ultimate edition for full support.

Posted in Domino To Spring, Uncategorized

Deploying Your Applications

Posted on February 13, 2017 by qtzar

So you have decided what you will write your application in, both backend and frontend, you have decided where you will store the source code and how you will track issues, you have figured out your authentication and authorization solution, all that is missing now is somewhere to actually run the application so people can use it. In the Domino world this was a simple solution, just put the NSF on the server, but when you leave the Domino world it because probably one of the hardest decisions.

First you need to know ‘HOW’ the application runs. If you have decided on Java for the backend then how does that run, do you deploy fat jar files that contain Tomcat web servers? Do you use skinny jar files that need to be deployed to an application server like WildFly or IBM Websphere Liberty. Using .NET then maybe you need to look at an IIS Server. What about the frontend? Where does that run do you need a server just for that or will it run on the servers the backend code is running on?

Then you need to ask if you will be running this all in-house or using a cloud provider like Azure, or Amazon Web Services. Do you use a container system like Docker or CloudFoundry?

At this stage you probably wish you could keep Domino around….

Because we decided to use Spring Boot we started looking at Pivotal CloudFoundry as our deployment solution but ultimately found that to deploy a Cloud Foundry solution on our Azure infrastructure might be very costly, it involved about 50+ VMs, additional cores and the Pivotal consultants we contacted really didn’t seem too interested in our business unless we were going to spend upwards of quarter of a million…

Next we looked at Docker. The best way to ‘think’ about docker is that you have a server which is the Docker host and then on that you have Docker containers which could be described as mini virtual machines, technically they aren’t but it is easier to think of them that way starting out. Docker on it’s own is just a technology stack just like HTTP is just a web stack. To make it useful you also need to look at Container Orchestration. This is the layer that manages all your Docker hosts and Docker Containers.

Orchestration layers include Docker Swarm (built in to Docker), Kubernetes, Apache MESOS and Cattle to name just a few. Cattle is one you may not hear of by that name but you may hear of Rancher. Rancher is the UI to Cattle but Rancher can also manage Docker Swarm and Kubernetes and it was this capability that draw me to looking at it. Rancher can also manage multiple environments so if you have a set of Docker hosts dedicated to your QA environment and a set of Docker hosts for your production environment then Rancher can keep them all separate for you.

So as you probably guessed we decided to deploy our applications using Docker containers running on Docker hosts which are running in Azure VMs using Rancher/Cattle as the orchestration layer. This turned out to be a great choice as we could then tie it all back in to our Microsoft Visual Studio Team Services build and release system which I’ll discuss in later posts.

Tagged with: , ,
Posted in Domino To Spring, Uncategorized

Managing your source code and issue tracking

Posted on February 10, 2017 by qtzar

If you are part of a team of developers and you are not using source control then you really need to start, if you are a sole developer and you are not using source control then you also really need to start. Source control is your friend, it will record all your code changes, it will merge in changes from different team members and allow you to manage new features and hot fixes with ease.

Alongside source control you also need to look at a system to manage your issue tracking and it is always a good idea to try to pick a combination that can talk to each other so that you can easily link your source control commits to particular issues. Doing this gives you a more accurate history of the application and allows you to quickly see why a particular change was made.

In the past I have recommended Redmine and Mercurial. Redmine is a free and open source issue tracking system and Mercurial is easy to set up and integrate with it. Both are excellent solutions and could be used with any development stack going forward.

For our new stack, however, we decided to look at other options. I looked at Pivotal Tracker which could integrate easily with GitHub. I looked at Jira which could integrate with Bitbucket or Github but ultimately ended up looking at a Microsoft product…

Yes, you heard me correctly we ended up looking at a Microsoft product even though we had decided on using Java as our backend code. Even 5 years ago the very idea that Microsoft and Java would be in the same sentence together was pretty laughable but times change and they now have some excellent java tools and sample code and even Eclipse and IntelliJ IDEA developer toolkits.

We looked at Microsoft Visual Studio Team Services (VSTS) because another team within the company was also starting to use it to manage issue tracking and build management for our new Microsoft Dynamics AX deployment. It made sense to investigate it and after testing all the features and capabilities we discovered that it did everything we needed and the logical conclusion was that we should standardize on the tool instead of having different systems for the different teams.

VSTS is free for 5 users, it is cloud based so you don’t have to set up any servers to get up and running and there are plenty of integrations in the VSTS Marketplace. It has its own GIT repository system or you can integrate it to external source repositories and has full Agile and Scrum based issue tracking systems that are very easy to customize.

I highly recommend looking at VSTS if you are ever in the situation of looking for a new issue tracking and source control system and in later blog posts I’ll also be talking about how it is also a build and release management system.

Tagged with: ,
Posted in Domino To Spring, Uncategorized

Who Are You?

Posted on February 8, 2017 by qtzar

In the Domino world we had the NAB (Notes Address Book) or Domino Directory as it eventually became known as. The NAB stored everything, from server configurations to policy setups and of course People and Groups. Each individual NSF had its own Access Control List (ACL) that would list who had access to the NSF and what level of access they had, also in the ACL was a mechanism to assign roles against the people and groups listed in the ACL. The NAB specified who you were and the ACL specified what you were allowed to do.

When you look at replacing this functionality you need to break it down in to multiple parts… Directory, Authentication and Authorization.

Directory is where you store a list of all the people that are allowed access your applications. If you are only building internal applications then you probably already have a directory which is either AD if you are a Microsoft house or some other LDAP directory if you are not. If you are developing applications that anybody can register to use then AD/LDAP may not be the best idea and you may need to keep that person data in its own separate database.

Authentication is the process of logging a user in to your system against the directory of your choice. Does the person exist, did they identify themselves correctly with the right password or other identification method, Do they need to register as a new user etc.

Authorization is determining if the person who has authenticated has access to the application and if so what roles they are assigned in that application, keeping in mind that they may have access to many different apps in your organization so your directory needs to be able to store all that info for you.

None of these things are supplied for you out of the box regardless of which backend and frontend you decide to use. You will either have to roll your own and hope it is secure or you can go with a third party solution.

The two that I recommend looking at are StormPath and Auth0. Both of these services can hook in to your in-house directory and can also supply a credentials store for external people to register against. They both provide application roles capabilities so people can have different roles in different apps, and they can both do two factor authentication and sso etc. They both allow sign in using facebook, twitter, google credentials etc. They both integrate with Spring Security which is something that we will be using as part of Spring Boot. They are both great products.

We went with Auth0 as our authentication provider. Auth0 can hook in to Azure AD which is where our corporate directory exists allowing us to provide a single sign on solution to our staff. We will, in the future, need user registration for some external facing apps and Auth0 can easily handle this for us and store the data for it. if you don’t need the Azure AD integration then StormPath has some fantastic Spring Boot starters with Thymeleaf support that can help you get going very quickly.

Tagged with: ,
Posted in Domino To Spring, Uncategorized
Archives