Monthly Archives: April 2018

How to setup Tomcat with AWS Loadbalancer SSL offloading

Category : How To

Recently I ran into an issue with an application which was running in tomcat.  My plans were to run an AWS Application Load Balancer which would offload the HTTPS Certificate from the application servers.  The problem is that my application was writing full path URLs based on the server name tomcat was hosted on.

This post will walk through the process of setting up your Tomcat application to be able to offload SSL certificates to a load balancer event if you have full path urls embedded in your code.

Step 1:

The first step is to setup your domain name, which you will use for your application.  My personal preference is to go with Route 53, as it’s baked into AWS, you can get free certificates to host on your load balancer and you get a lot of other benefits in regards to how routing is handled.  This domain name will be needed for the next step.

Step 2:

Create your EC2 instance, and install tomcat. In your CATALINA_HOME directory open the “conf/server.xml” file.  Scroll down until you find the “<Connector>” lines.

<Connector port="8080" protocol="HTTP/1.1"
           connectionTimeout="20000"
           redirectPort="8443" />

Once you find this segment, copy it and paste the copy right below the line in the server.xml file.  You’re then going to set the port to a different port number (such as 8081) and add in lines which will tell tomcat that it should behave as if it were encrypted and hosting the domain.

<Connector port="8081" protocol="HTTP/1.1"
           connectionTimeout="20000"
           proxyName="YourDomainName.com"
           secure="true" scheme="https" SSLEnabled="true" />

Save the file and restart tomcat

Step 3:

At this point you need to setup your SSL certificate.  To do this you’ll need to navigate to “Certificate Manager” in your AWS console.  Once there you’ll need to request a certificate.

The certificate will need to verify that you own the domain.  If you used Route 53 it will give you an option to add a CName to Route 53 by clicking a button (this is probably the easiest way to verify the domain).  Once you do this, you’ll need to wait for AWS to verify your certificate.

Step 4:

Now that you’ve setup all the pieces, your ready to setup your AWS Application Load Balancer.  To do this navigate in the AWS Console to EC2 and click the Load Balancer option on the left hand navigation menu.

This selection will take you to the list of your existing load balancers.

Click the “Create Load Balancer” button on the top of the screen.  Then select “Application Load Balancer”.   On the next screen type in a name for your load balancer, set the protocol to “HTTPS” and finally set the availability zones for your load balancer in your VPC.  Click the next button.

On the next screen, select the certificate you setup in Step 3, then click next.

The next screen will prompt you to select a security group.  On this step you can either go with the default, but more than likely you’ll want to have a security group strategy to limit access to your server, but in this example we’ll go with default.  Click next.

By default the wizard will want to create a new target group.  Here you’re going to fill in the options simular to the following, but feel free to be creative with the Name property.

Click the next button.

Finally select your server instance you setup. Click next, then click create.

Step 5:

Once your Application Load Balancer has been created, the last step is to setup your Route 53 A record to point to your load balancer as an alias.

 

Once you finish updating route 53 your domain name will now work with HTTPS while your Tomcat server runs without a certificate using HTTP, offloading encryption to your load balancer.


Robust Rest APIs with Serverless Micro Service

Category : Uncategorized

I’ve worked for various companies which both wanted to present a robust set of APIs on a single URL, as well as develop with a Micro Service architecture.  While there are various design patterns which I’ve used, the draw back in terms of complexity or singular bottlenecks for development and release always made that dream difficult.  It wasn’t until I got into serverless architectures where I’ve discovered that there is a simple way to build your robust verb based APIs while keeping the Micro Service architecture and mindset intact.

This blog entry is going to talk about how Lambda and API Gateway can be used in conjunction to allow you to create robust rest interfaces while allowing you to have multiple teams develop and own portions of the API without conflicts in the development or shared resources.

Leveraging API Gateway to decouple your API

API Gateway and Cloudformation nested stacks are probably one of the best combinations I’ve used when it comes to defining restful interfaces.  The first step is to leverage a basic design pattern where you’re going to define your parent API Gateway resource, and then define your sub-resources in nested cloudformation templates by passing in the API Gateway reference as a parameter.

This approach accomplishes two things.  First you now have a resource which can be deployed independently from other APIs, and secondly, you’ve created the framework for your micro service and their infrastructure definitions.  When deployed you’ll have a single url with a holistic and robust API.

The Lambda Micro Service

Once you’ve defined your parent and child cloudformation templates, which can either live together or be hosted in separate source control repositories, it’s time to build out your lambda micro services.  By leveraging the newly built child Cloudformation templates as container, we can now define our lambda infrastructure, roles, permissions and database resources (such as RDS or NoSql options such as DynamoDB).

Since we’ve built our child templates to only rely on parameters passed in, this enables us to deploy out a single resource to a test environment, or multiple combine multiple to generate our robust API capabilities.

Benefits to Approach

This approach, while simplifying your cloudformation templates and grouping together related infrastructure definition, also changes the way which new APIs can be developed in an organization.  Limitations around centralized resources goes away, multiple teams can work on different parts of the API in parallel, and finally your API components can be released independently, allowing your teams to move at their optimal rate without having to wait for other non-related aspects to get completed, integrated or through a UAT process.  From my perspective though, the ability to get a Robust API to market quickly, leveraging multiple teams, departments and vendors, might be the biggest reason to go in this direction.


AWS and SOA (Service Oriented Architecture)

When I first got introduced to the Spring framework it allowed me to re-envision how to construct objects to work together while enabling more diverse capabilities by constructing variations of object, decoupling architecture and finally increasing test-ability and test driven development.  This is accomplished through a two aspect approach.  The first aspect is Interface & Object definition, the second aspect is orchestration & assembly.  SOA then breaks this model out into the following layers: Consumer, Integration, Business Process, Service, Component and finally the Operational System Layers.  These capabilities allowed me, and other developers, to construct adaptable SaaS (Software as a Service) systems which supported higher customization while limiting the amount of new code and maintenance required on these systems.  The downside to this is that you ended up either having a monolithic service which would then be deployed multiple times or you’d end up with a lot of micro services which would then need an orchestration layer tailored to your needs.

Cloudformation

AWS Cloudformation allows developers to spin up and connect services and infrastructure in a way which is repeatable and reliable.  When I started I was trying to build my entire solutions in a single cloudformation, or separating them into segments then connecting them together through direct reference.  Nesting stacks became a way to organize infrastructure into segments which were functional.  What I missed what that the design pattern which opened up my ability to create highly flexible and adaptable systems was just waiting to be used.

SOA Cloudformation

Cloudformation’s nested stacks concept isn’t new, but it is powerful.  Taking a look at your serverless infrastructure or traditional infrastructure, you can then start breaking out your micro-services into individual definitions.  These definitions could be general purposes or could be custom development for a specific consumer model.  Once you’ve created various definitions for these individual components the nested stack can then be used to wire these components together, or to put it another way orchestrate a specific configuration which will cause services to interact without having to be hard coded to do so.

Lets take a look at an example.  Lets say you have a telecom customer portal your company provides as a SaaS offering.  You have two customers.  Customer A has a specific UI which provides a dashboard back to their customers, which is then connected to a middle tier customer profile service, a billing service and various others.  The billing service is then tied to other services which handle payment processing, bill history, etc.  Customer B is pretty much the same with a few differences around UI and they have different requirements around billing history.  In a more traditional model you’d either end up putting all the configuration into the services via transforms which would have to live with the code, or you’d have to have a centralized configuration system, which I’ve built before and just add another layer of complexity and maintenance.

If leveraged correctly, cloudformation nesting can accomplish this same objective, while allowing for an even high degree of flexibility and diversity of your application.  This is especially true if you leverage decoupling strategies such as SNS and SQS.

The first step is to define your services and components.  In the above example we’re looking at two customer user interfaces,  a business processing service, a profile service, two billing history services, a payment service and an upgrade service.  Our first step is to define these services as unique cloudformations, exposing configurations, such as other services urls or Arns, as parameters.  This does two things.  First it ensures your component’s specific configuration is easy to read and understand as you’ve isolated it from other components, and secondly you’ve just made it possible to deploy that specific component to an environment of mock interfaces for isolated unit testing.

The second step is to actually connect your services through cloudformation nesting.  Up until this point, your services needed to know the messages which they would send and receive, but wouldn’t know specifically who they were sending them to.  Nesting the templates allows you to now connect the services you’ve created by referencing each other, allowing you to easily create customization, standalone deployments or even side by side systems without increasing the complexity of any single component,

While I personally see the benefit of this design pattern really applicable to the serverless world, it can be used in a more traditional infrastructure environment as well.

 


Making big decisions small decisions

Category : Insight

“BIG” decisions stop progress.  They are the decisions which must be thought about, must fall in line with strategy, finances and alliances.  These decisions can limit who you target, how you operate or even how innovative you decide to be.

Some of the big technology trends lately have made a huge impact on the size and scope of what used to be the “BIG” decisions.  This trend has impacted apps, infrastructure and even skill set requirements.  This post is going to dive into a couple of examples of these technologies to show actual examples and how they impact decision making for businesses.

App Development

A “BIG” decision around apps has always been which platform are you going to build your app for.  Are you going to go after the iPhone crowd, the Android crowd?  Do you have the time to build a Windows phone or desktop app?  What devices are your users more likely to use, and will it effect them if only a portion of their social networks have access to your app?  Believe me, hitting only a section of someone’s social circle can spell doom.  The problem here though isn’t just a technology problem, but a people problem as well.  iPhone developers aren’t typically Android developers.  If you’re going to hire in house for this position then you suddenly need to hire, maintain and develop the various skill sets needed to build your apps.  If you hire a consulting firm, then you’re looking to oversee duplicated effort across the various devices your app is being built for.

The good news is that there’s technologies which can help.  Cordova is an example of a technology where your website developer can use their skills to develop an app on Android, iPhone, Kindle, Windows Phone, Windows Desktop, etc.  The tools used are html, css and javascript, which are skill sets typically needed to build and maintain modern websites.  While there is a bit of a learning curve around navigating operating systems to build the app, the benefits of a single set of code for all apps greatly outweigh the learning curve.

Two notes building on this technology.  While you can write a single app for all devices, it is important that you build your apps to be responsive to the type of device its being viewed on.  The expected experience for an Android user is different than the experience the iPhone user will expect.  While these variations are minor, a mature app will take these into account.  The second note is that if you’re web developer is on a windows system, it is pretty cheap to get a cloud based Mac to build your iPhone app on.  I personally use MacInCloud.

AWS Cloudformation

Building out your data center has always been a BIG investment, then the cloud came along and the immediate material investment decreased.  You still end up requiring people who understand how to configure the cloud environment. As part of that your decision as to where you host your infrastructure and if you’re going to setup a site for production and for development purposes.  This meant lots of manual work which could lead to slight variations which could have big impacts.  On top of all of this you have to maintain a staff of network administrators to maintain your cloud which is a separate skill sets as those of your developers.

Now enters a set of cloud tools which turn these big decisions into small decisions.  AWS Cloudformation turns your infrastructure into a template which can be deployed at will, with very little knowledge as to how to configure the details needed after the Cloudformation has been built.  Suddenly, if you decide to start hosting your data on the West Coast of the US, then learn that the majority of your users are on the east coast, with a click of a button you can deploy what you have on the west coast to the east coast.  If you decide that you want three different instances of your site, such as a partner site to test out changes with your partner companies before you go live, your developers should be able to click a few buttons and get one setup which mirrors your production configuration.  If a disaster happens, getting your business up and running becomes clicking a few buttons, if its not just automatic.

What this means to your business is that you are going to spend some time and money up front, but you gain flexibility in decision making from this investment. Cloudformation is just one example, but other cloud providers have comparable options (such as Azure Resource Manager).  In all cases you position what use to take manual effort and weeks (if not months) of work into a push button solution.

One note on this technology.  I would personally recommend spending some money up front to get a Solutions Architect to put together your initial Cloudformation, or comparable template.  This individual will make sure you’re setup for success and placed in a position where you have more options to do what will make you successful.  With current trends towards developers having more responsibilities around designing and supporting their application infrastructure, your developers will more than likely pick up extending and maintaining your Cloudformation templates.

Conclusion

Some of the latest technologies are making those “BIG” decisions into small decisions, which can at a blink of an eye be altered.  This changes the game when it comes to taking risks and innovating, making the former easier to tolerate failure of a single assumption and allows more effective adaptation.


Bitnami