Internal apps
Skyliner started out focused on making it easy to launch web apps on AWS — specifically, apps that serve HTTP/HTTPS traffic to the internet. A very common request, though, is the ability to launch internal services, not accessible to the internet, using the same deploy and scaling tools we provide for public web apps. We’ve now added internal app support and it’s available today.
To create an internal app, just choose “Advanced options” in the app create form, then select “Accept internal traffic only” under Access:
That’s all there is to it — the app otherwise will perform and be managed exactly like any other Skyliner app.
Internal apps are available to other apps or resources within the same environment and region. For instance, if you launch an internal app to QA in us-west-2, another app in QA in us-west-2 will be able to reach it. Apps in us-east-1, or in Production for us-west-2, will not.
You can test out your internal app very easily using a Task on another app in the same environment and region. Let’s say that in us-west-2, you’ve deployed an internal app, service-test, to QA, and you have another app, frontend, also deployed in QA. First, go to the Status page for service-test, and copy the link from the Your App (QA) button. That should look something like http://internal-qa-service-test.121212121.us-west-2.elb.amazonaws.com/. Then, go to Tasks for frontend and add a task that looks like this:
Here’s the script text so you can copy it more easily:
apk --no-cache add curl && curl --silent --show-error --head --max-time 3 <YOUR URL HERE>When you run that script, it will show you the successful connection to the internal app:
Tasks are generally useful for testing things out inside your app environment, as in this case.
One advanced topic note: people who are porting a set of apps to Skyliner sometimes use VPC peering to move one app or service over at a time. If you launch an internal app to an environment (QA or Production) that has a peered VPC, applications in the peered VPC will be able to reach the internal app as well (assuming you’ve set up routes to allow that).
We’d recommend that you resist the urge to create a ton of microservices for each slice of functionality in your app. This is a much-discussed pattern of late, but we’ve seen it lead to Rube Goldberg-eqsue deployment scenarios, where attributing an outage or error becomes far too complicated. Separating out chunks of a service that have truly different security, reliability, or isolation needs makes sense, but otherwise, as always, we recommend you keep it as simple as possible. Use internal apps in moderation and life will be easier.
Let us know how this works for you, and what else we can add that might be helpful.
