0 comments on “Memory Consumption in Spring and Guice”

Memory Consumption in Spring and Guice

Spring vs guice

The heart of the Sunshower.io platform is a distributed virtual machine that we call Gyre. Developers can extend Gyre through Sunshower’s plugin system, and one of the nicer features that Gyre plugins provide is a dependency-injection context populated with your task’s dependencies, as well as extension-point fulfillments exported by your plugin. For example, take (part) of our DigitalOcean plugin:

The details are beyond the scope of this post, but basically Gyre will accept an intermediate representation (IR) from one of its front-ends and rewrite it into a set of typed tuples whose values are derived from fields with certain annotations. The task above will be rewritten into (ComputeTask, Vertex, TaskResolver, TaskName, Credential). This tuple-format is convenient for expressing type-judgements, especially on the composite and recursive types that constitute Gyre programs.

As an aside, there are Gyre rewrite rules that can infer recursive and co-recursive types (think singly-linked lists) up to a configurable depth. Sunshower.io uses Spring extensively, and it was quick and convenient to, for a given program, subsequently rewrite a Gyre program into a set of typed tuples, union those suckers together, and if the resulting tuple was satisfiable, create a Spring ApplicationContext with all of the dependencies, start it up, and then execute the program in that context.

For quite a few tasks that we’ve encountered in the wild, these tuples can grow quite large, and so I was curious as to how memory utilization would grow relative to Gyre program size.

We have used Sunshower.io’s optimization capabilities to analyze our own workloads, and for current uses, 4 GB heaps work quite well for us from both a cost and performance perspective. However, we don’t have much experience with thousands of concurrently-executing Gyre programs outside of simulations, so I wanted to figure out how badly using a Spring ApplicationContext per Gyre program would burn us, if at all.

The Setup

I wrote up a quick utility to inspect the size of an object using Java’s Instrumentation mechanism. Basically, we just perform a breadth-first search of the object graph and sum the individual sizes of each field as reported by java.lang.instrument.Instrumentation (feel free to ask me for the code — I haven’t had time to open-source it, but I do intend to).

Spring

Now, I used the Gyre to generate a configuration that looks like the following:

Now, testing it out yields the following memory utilizations for different numbers of beans

line graph showing the size, in bytes, of memory utilization

(All sizes in bytes)

Now, Spring has a lot of features, and is correspondingly large. The base size of the object graph of a AnnotationConfigApplicationContext is ~3.2 MB. The size of an empty, loading AnnotationConfigApplicationContext is ~4.7 MB. Now, there isn’t a whole lot of information to be gleaned from this, other than that Spring has a (relatively) large initial memory footprint. The good news is that it doesn’t grow very quickly. As an example, with all of our existing plugins loaded into their own application contexts, as well as Sunshower:Stratosphere, Sunshower:Core, and Sunshower:Kernel (about 10 individual application contexts and about 1400 services, including a JPA context), the total application size is ~78 MB. Is that a lot? Not at all — remember our 4GB heap. As a percentage of available memory, that amounts to a paltry 1.95%.

However, the problem is that we have to serve thousands or tens of thousands of these application contexts per minute. An empty Gyre graph will set us back 4.7 MB, which will allow us to have ~850 concurrent Gyre operations/node at best. And that doesn’t allow us to have any user data at all. That’s a bit of a problem for us. So, in an effort to reduce Gyre memory footprint, I decided to look at Google’s Guice.

Guice

The setup is basically the same. I generated a Guice Module, once again using Gyre, that looks like:

This used a pretty paltry 0.11 MB on average, which remained largely unchanged even as we defined several of the required services from our Spring application context into the Gyre Guice context. That allows us to easily meet our target of 500 concurrent Gyres per node without eating into our user data space.

line chart showing how guice's memory usage compares to Spring's

Final Notes

I want to point out that, relatively speaking, very little application time and application memory are typically consumed by application data. We are certainly not moving the entirety of Sunshower.io from Spring to Guice. Guice and Spring are both quite modular, and Sunshower.io uses virtually all of Spring’s modules. This is to say nothing of the heavy dependency we have on Spring Test. We only required dependency injection in the Gyre, and Guice turned out to be a memory-efficient way of providing that.

0 comments on “Looking for Free Cloud Credits? These 7 Discounted Startup Programs Can Help You Move to the Cloud”

Looking for Free Cloud Credits? These 7 Discounted Startup Programs Can Help You Move to the Cloud

It’s tough to get started on the cloud. There are so many options, and confusing pricing structures can make the whole process seem overwhelming. Fortunately, there are lots of great programs dedicated to giving startups access to the resources they need to be successful. (Yes, even free cloud credits!) Before locking yourself into a relationship with a cloud vendor, check out these seven discounted startup programs. Applying can give you a great chance to play around with that cloud’s processes and pricing structure without spending more than your budget can handle.

AWS Activate

The credits and perks you’re offered from AWS Activate depend on which package is the right fit for your startup. The Portfolio package includes $15K in AWS credits over 2 years. The Portfolio Plus package gives you access to $100K in credits over 1 year. (AWS business support and training are some of the other perks of Activate.) The Portfolio and Portfolio Plus packages are available to startups that are associated with an approved accelerator, incubator, or VC Fund.

If your startup doesn’t qualify for AWS Activate but you’d still like to get hands-on experience with AWS, you’re in luck. AWS also offers a free tier, which gives new uses free access to over 60 of their tools for 12 months. It’s a great way to learn and experiment with AWS — just be careful to stay within monthly limits!

Create@Alibaba Cloud

Create@AlibabaCloud offers qualifying startups $2K to 50K in credits. You maybe eligible if your startup is a) registered outside of China, b) been in business less than 5 years, c) has less than $500k in annual revenue. And, bonus, you get priority if you’re not on Alibaba Cloud yet.

Google Cloud for Startups

Google Cloud offers new users $300 in credits for a year at https://cloud.google.com/free/, but you may also be interested in their three Google Cloud for Startups programs. You may qualify if you’ve raised no more than a Series A and are less than five years old, getting $3K to $100K in credits for the year.

Hatch by DigitalOcean

Build and scale your startup using the Hatch program and receive 12-month access to the DigitalOcean cloud with up to $100K in credits. Hatch also includes technical support and mentoring, along with a host of other tools.

Hatch program isn’t for you? DigitalOcean is also currently offering a $100 credit over a 60 day free trial period. There’s no affiliation with an incubator or accelerator required for this one, but it’s for new users only.

Microsoft for Startups

There are two options here. The first program is available to all startups, and includes $200 in Azure credits over 30 days. The second program is available to startups who meet their qualification criteria (company should be less than 5 years old, offers technical solutions, less than $10M in annual revenue, under $20M of funding, and associated with an accelerator or incubator), and includes up to $120K of free Azure cloud services over 2 years.

Oracle Global Startup Ecosystem

Oracle’s startup program bills itself as an “acceleration program,” so the application requirements are a little different from some of the other programs. Affiliation with VC firms, incubators, or accelerators isn’t required, but they’re interested in funding companies focused on “transformational technology.” If this describes your company, Oracle Global Startup Ecosystem could be a great opportunity to access free cloud credits, mentorship, training, and support.

Startup with IBM

IBM offers two tiers of support to startups. The Builder program includes $1000 a month in cloud credits over the course of a year, and doesn’t require affiliation with an incubator or accelerator. The Premium program supports companies involved with an approved accelerator or incubator that are focused on developing “innovative technologies.” If you qualify for the Premium program, your startup could receive $10K a month for a full year.

Before You Apply

There are lots of great opportunities out there for startups looking to get started on the cloud. Keep in mind, though, that most of the programs on this list are only available to new users, and some require your startup to be affiliated with an approved accelerator or incubator to qualify. Please check with the individual vendors to verify program details and eligibility before applying.

Once you’ve gotten started on one of these discounted startup programs, you’ll have the tools you need to start experimenting with the cloud. Sunshower.io can be an important part of that plan, too. When you’re just starting out on the cloud, the learning curve can seem pretty steep. Sunshower.io has the right tools to help you easily and intuitively manage the entire lifecycle of your cloud infrastructure. Our drag-and-drop deployments and unbeatable optimization algorithms are all designed for simplicity and ease of use. Whether you want to deploy software on the cloud, track workloads, or view all the spiffy new infrastructure you’ve built, you can master the cloud with Sunshower.io. We’re here to help your company succeed by demystifying cloud computing so you can focus on what matters — your business.

0 comments on “Depends for the Deep End”

Depends for the Deep End

Seven Lessons about Tech and Life

As an artsy, outdoorsy type and a middle school humanities teacher in my mid-thirties, I am the last person you would expect to see in the role of intern at Sunshower.io.

Perhaps we can blame Marie Kondo for my transition into web development: I started off cleaning my house and by the time it was decluttered I had a new career plan. More likely we can point our finger at a bottle of wine and a dead-end career in education. Together, they conspired to make me complain to my sister and brother-in-law over dinner about my professional woes. (My sister and brother-in-law are the CEO and CTO, respectively, of Sunshower.io.)  By the end of our meal, he had suggested I go into tech and she had given me an internship.

That was four months ago. The past few months have taught me a few lessons about tech and life:

Lesson #1: You have to start somewhere, and you’re not going to learn it all in a day.

I started with Sunshower.io knowing the bare minimum of the tech it takes to keep a 21st century classroom running. I certainly did not know about IAM or AWS or cloud optimization or why one would care about any of it.

Lisa and Josiah showed me crazy computer things that I had never seen before: pug, github, git, command terminals, Docker, and dev environments. We like to call this steep learning curve “Depends for the deep end” because, sometimes, you end up over your head in code and it’s so scary you want to pee yourself.

Honestly, needing Depends for the deep end is not only okay but expected. Lisa started off her software engineering career with a wee bit of CSS and HTML and a master’s degree in public communication and technology. Josiah was a math major. They both taught themselves everything they needed to know (using life lessons 2 and 3; see below), and they still have days where they have to ask each other questions or take brain breaks to figure out solutions.

Where does this leave me? Having a lot more patience for the learning process. Whether you learn a little bit every day–or, per the Sunshower.io experience, a lot in one day–you will start stockpiling an impressive amount of know-how.

Lesson #2: When in doubt, look it up online.

While Sunshower.io’s people look out for each other, it is also a culture of rugged individualism. When you are working for people who built up their skill set from scratch without help, there is minimal patience or time for hand-holding.

You have to learn to find answers on your own. And you will.

Lisa broke me of the habit of asking too many questions early on. When I would ask her something easily answerable, she would ask what I thought or whether I had looked it up. Pretty soon, I would answer my own questions before she could reply, and finally I stopped needing to ask. Except for unanswerable structural questions, that is, which leads us to lesson 3.

Lesson #3: If you can’t find it online, ask.

For a newb, solutions are easy to find online. However, when you are collaborating on projects like Sunshower.io’s visual modeler, distributed virtual machine or cloud optimization machine learning algorithms, in the end you often HAVE to ask about the factors that might be standing in your way.  

Lesson #4: Be patient. Tech is a rollercoaster of successes and failures.

Some days, your code will work perfectly. You will build something awesome and post your progress on social media. Your dev environment will load perfectly, and you can check off your to-do list in an hour.

Other times, you will run commands in your terminal, and it will take hours and still won’t work. You will run tests through your IDE, and it won’t work…and won’t work…and won’t work.

Lisa taught me that a big part of tech is being comfortable with the failures and dead-ends. Your code won’t always work. And that is okay. Maybe tomorrow you will ask the question that leads you to the solution you need, or perhaps the quick-fix to your broken code will dawn on you at a gloriously random moment.

So pour yourself a cup of coffee, sit in front of that computer screen, and buckle your seatbelt. See where today leads you.

Lesson #5: Have a dog close by.

Between the three founding members and me, we have three dogs, and they are always close at hand. When Sunshower did its QA night, during which we ran the web application with three people clicking buttons simultaneously, we ran tests while dogs roughhoused in our laps and under our feet.

Lisa and Josiah’s mini aussiedoodle Fran forces them to take breaks. Lisa’s brain breaks involve playing with Fran on the floor, and Josiah takes Fran for long runs before he starts working for the day.

In addition to forced breaks and relieved tension, dogs simply remind you not to take tech or life in general too seriously. Having a dog roll over on your laptop keyboard or drool on your computer screen reminds you that, no matter how important your tech projects are–and they are–they are just tech projects.

When the going gets tough, rub that belly or scratch those ears. You’ll figure it out. We promise!

Lesson #6: I will never, ever work as the chief of anything for a company. Ever.

Despite what I knew about Lisa and Josiah’s work days, I tended to romanticize what they did. Work all night? Sleep until noon? Take breaks when you want? Code your way to your dream life? Yes please! Sign me up!

I did not truly comprehend their daily grind, and I seriously questioned their love of cartoons as entertainment (really guys?), until I started working with them. Their work days start at ten in the morning and go until midnight if they are lucky. Josiah has been known to pull multiple all-nighters a week while tackling infrastructure projects. Lisa had chronic shoulder and forearm pain from typing for 14 hours a day that was only cured by throwing down over $80 for a split keyboard.

However, these epic workday ultramarathons have paid dividends. This week, they came in second place in the pitch competition at Fort Collins Startup Week. They have six clients and more in the wings. It is commendable. Truly.

And I would not wish it on anybody.

Lesson #7: Tech is about people, experiences, and services.

Tech is not just about the code you write or the tests you run. It is about connecting with Lisa and Josiah about their QA needs and with Tif about blog posts like this one. It is the Sunshower.io home office: a north-facing former bedroom in their Fort Collins home, the window opening to farmland. It is the late-night walks that help you work out your code, the new people Lisa adds to LinkedIn, the friends I have made through tech meetups. It is the hundreds of hours spent on a service that can save companies thousands of dollars on their monthly AWS bill. It is the scrappy tech stars working long hours to bring their services to life for future clients. Code is only the beginning.   

This is Julie Gumerman,
Sunshower’s unlikely intern.
0 comments on “Save 40% or more in 40 Seconds”

Save 40% or more in 40 Seconds

Illustration of an open storage unit partially filled with cardboard boxes

Sunshower.io’s optimizing algorithms help you save time and money on the cloud. There’s no upfront cost, and our results are better than our competitors. So how do we do the thing?

Imagine you need to rent a storage unit — you have a bunch of boxes, but nowhere to put them. No problem! There are a ton of companies out there that will rent you a storage space. You do a quick search, and find over 30 self-storage companies scattered across town. You don’t have time to talk to everyone to compare prices (who does?), so you call a company whose name you recognize. You’re not exactly sure what size storage unit you need, so they talk you into renting a 10 x 20 unit, “just in case”, at which point you end up with a storage unit that looks like the photo above.

End result: you’re paying for a lot more than what you need. Sure, you could move to another facility, but who wants to negotiate with another company, then give up their whole day to move a truck and switch facilities? Easier to stay put, and keep that extra space.

Buying too much “just in case” is a very common things for companies on the cloud, too. Why?

  • There are an overwhelming amount of cloud service provider choices
  • There are an overwhelming number of options on each of those cloud service providers
  • The UIs of cloud service providers are confusing
  • It’s hard to know exactly what you need and what you’re using

That’s where Sunshower.io comes in

When you work with us, we securely run metadata about your resource usage through a proprietary algorithm designed to find the exact right fit for your cloud needs. We use machine learning to calculate millions of data points, factor in fluctuations in data usage over time, and come up with a cloud plan that ensures you aren’t overpaying “just in case.” We find you a fit so good, we can save our customers 40% or more on their monthly cloud compute bill.

(Think Cinderella’s glass slippers, with good arch support and just enough wiggle room for your toes.)

Over time, this kind of cloud savings can be game-changing. Just imagine the decisions you could make even with an extra 20% of your monthly cloud spend back in your pocket, like hiring another engineer, or launching a great social media campaign. And that’s what we’re all about at Sunshower.io: helping you focus on what matters — your business.

To that end, we’re excited to announce our just-launched AWS EC2 optimizer

If you’re currently using Amazon Web Services EC2 for your cloud infrastructure, our service (colloquially known as Anvil) has been specifically tailored to analyze your data and come up with a better plan for your cloud usage. The bottom line: We can help you save money on AWS with just a few clicks.

Not using AWS EC2? We promise you won’t be left out. We’re launching AWS RDS optimization next, and we’ll be releasing optimizations for more public clouds as we go along. (Google Cloud and Azure are next up on the list, but let us know your needs and we can re-prioritize!)

0 comments on “‘Cloud Management Platform’ Undersells It”

‘Cloud Management Platform’ Undersells It

Silhouette of one person helping another person up a hill

Because we need a snappy way to refer to what we do, we call ourselves a ‘cloud management platform.’ But that undersells it. Why? Because cloud management platforms and solutions are for the big guys — the ones with IT budgets the size of small countries, or at least small counties. Twee though it may sound, we want to be the great equalizer for cloud computing, supporting engineers of all stripes.

Why does this matter?

More and more, engineers aren’t coming from a Computer Science background, they’re coming from code academies or more ad hoc backgrounds (hello, yes, I majored in journalism). And even when they are, cloud computing isn’t really taught in schools. So you wind up in a job, and suddenly you have to figure out how to deploy things. Or you start a company, and you realize “wow, I can’t just have this run on my localhost.” Or maybe your infrastructure is in the cloud already, and you realize you just wasted $200 on an instance you forgot about. Or your infrastructure is in the cloud and costing you the salaries of three good engineers a month, and you have to figure out how to keep the engineers and not the cloud cost.

And so the Googling and Stack Overflowing begins, except half the information is out of date because things are always changing, and the numbers are almost always wrong because cloud service providers are constantly changing their pricing structure. And don’t even get me STARTED on how or if you should containerize your software.

It is in these moments that you wish that there were some solution that could just do the thing for you — help you pick a cloud, help you migrate across clouds, help you deploy with Docker just like you had been with machine images, help you optimize your cloud costs.

And that, THAT is our why. Because no matter how new or how senior, there will be a moment when you don’t have the support you need. We didn’t pick the name ‘Sunshower’ because it was cute and fit with the cloud theme (okay, we kind of did). We picked it because dealing with the cloud shouldn’t have to be so dang hard. It should be able to be easy, and rewarding, and maybe even fun.

Need some help on the cloud? Visit us at Sunshower.io.
Spending too much on AWS? Learn more about our Anvil optimizer.

2 comments on “Unit-testing Aurelia with Jest + JSDOM + TypeScript + Pug”

Unit-testing Aurelia with Jest + JSDOM + TypeScript + Pug

All source can be found at: Aurelia-Aire

Testing UI components is one of the more difficult parts of QA. In Stratosphere, we’d been using Karma + Jasmine, but the browser component had been complicated by the fact that providing a DOM to tests in a fast, portable manner subject to memory and speed constraints can be pretty challenging. Sure, initially we did the PhantomJS thing, then Chrome Headless came out, but writing UI tests just never really felt natural.

Then, last week, we decided to open-source our component framework, Aire, built on top of UIKit+Aurelia, and that created an exigent need to fix some of the things we’d been limping along with, most importantly testing. The success of OSS projects depends on quite a few things, but I consider providing a simple way to get contributors up-and-running critical.

Simple set-up

Internally, Aurelia uses an abstraction layer (Aurelia PAL) instead of directly referencing the browser’s DOM. Aurelia will (in principle) run on any reasonable implementation of PAL. Aurelia provides a partial implementation OOTB, Aurelia/pal-nodejs, that will enable to (mostly) run your application inside of NodeJS.

Project Structure

Our project structure is pretty simple: we keep all our components and tests under a single directory, src:


aire
├── build
│   └── paths.js
├── gulpfile.js
├── index.html
├── jest.config.js
├── jspm.config.js
├── jspm.dev.js
├── package.json
├── package-lock.json
├── src
│   ├── main
│   │   ├── aire.ts
│   │   ├── application
│   │   ├── button
│   │   ├── card
│   │   ├── core
│   │   ├── core.ts
│   │   ├── dropdown
│   │   ├── events.ts
│   │   ├── fab
│   │   ├── form
│   │   ├── icon
│   │   ├── init
│   │   ├── init.ts
│   │   ├── loader
│   │   ├── nav
│   │   ├── navbar
│   │   ├── offcanvas
│   │   ├── page
│   │   ├── search
│   │   ├── table
│   │   ├── tabs
│   │   └── widget
│   └── test
│   │   ├── button
│   │   ├── core
│   │   ├── init
│   │   ├── render.ts
│   │   ├── setup.ts
│   │   └── tabs

...etc

At the top of the tree you’ll notice jest.config.js, the contents of which look like this:

Basically, we tell Jest to look under src for everything. ts-jest will automatically look for your Typescript compiler configuration, tsconfig.js in its current directory, so there’s no need to specify that.

Our tsconfig is pretty standard for Aurelia projects:

Test

If you just copy and paste our tsconfig.json and jest.config.js files while following the outlined directory structure, everything will Just Work (don’t forget to npm i -D the appropriate Jest and Aurelia packages.)

At this point, you can use aurelia-test to write tests a la:

hello.html

hello.ts

hello.test.ts

Now, you can run your tests with npx jest:

aire@1.0.0 test /home/josiah/dev/src/github.com/sunshower/aurelia-aire/aire
npx jest

PASS src/test/button/button.spec.ts
PASS src/test/tabs/tab-panel.spec.ts
PASS src/test/init/init.spec.ts
PASS src/test/core/dom.spec.ts

Test Suites: 4 passed, 4 total
Tests: 12 passed, 12 total
Snapshots: 0 total
Time: 3.786s
Ran all test suites.

Enabling support for complex DOM operations

That wasn’t too bad, was it? Well, the problem we encountered was that we use the excellent UIKit framework, and they obviously depend pretty heavily on the DOM. Any reference in Aire to UIKit’s Javascript would fail with a ReferenceError: is not defined error. Moreover, if we changed the Jest environment from node to jsdom, we’d encounter a variety of errors along the lines of TypeError: Failed to execute 'appendChild' on 'Node': parameter 1 is not of type 'Node' which I suspect were caused by pal-nodejs creating DOM elements via its own jsdom dependency while Jest was performing DOM operations using its jsdom dependency. In any case, the solution turned out to be to define a single, global jsdom by importing jsdom-global. Once we discovered this, we encountered other issues with browser-environment types and operations not being defined, but this setup.js resolved them:

At this point we could successfully test Aurelia + UIKit in NodeJS.

The final piece

All of our component views are developed in Pug, and I didn’t like that we’d be developing in Pug but testing using HTML. The solution to this turned out to be pretty simple: adding Pug as a development dependency and creating a pretty simple helper function:

With that final piece in place, our test looks like:

Conclusion

The benefits of writing tests in this way became apparent the moment we cloned the project into a new environment and just ran them via npm run test or our IDE’s. They’re fast, don’t require any environmental dependencies (e.g. browsers), and allow you to run and debug them seamlessly from the comfort of your IDE. But, perhaps most importantly, these are fun to write!

5 comments on “Gratitude as a Hedge”

Gratitude as a Hedge

I think everyone says that building a startup is hard, but what they generally fail to convey is how hard it actually is. I left my previous position on March 1st of this year, and since then it seems like it’s been an unpunctuated litany of 14-hour days.  There’s also this notion (that I had) that when you found a company, you’ll mostly be working on projects that are interesting to you. I mean, it is your company, right?  And you do generally get to choose what that entails, right? And that that engagement will be prophylactic against the darkness.

That’s pretty heckin’ far from the truth in every way.  About 10% of the code in Sunshower is what I would consider to be “strongly interesting”–the rest is fairly standard enterprise Java, Go, and Typescript.  In other words, Sunshower is 10% distributed graph reduction machine and 90% infrastructure built to interact and support that. It’s actually about twice as bad as that, since fully 55% of the code is tests and testing infrastructure.  And this is to say nothing of setting up continuous delivery, writing deployment manifests, replacing failed hard drives, configuring VPNs, signing documents, worrying about corporate and legal stuff…the list goes on.

That proportion of fun-work to work-work largely tracks my experience at companies of all sizes, with the primary differences being that the pay is much worse at your own startup, and that nobody’s really skeptical of a software project that is already profitable.  The cocktail of doubt, overwork, and scarcity is strong and bitter, and there’s only so much of it you can drink.

In October I got pretty sick and have only just really recovered, and that really pushed me to a place that the kids probably call “too extra.”  You can tell when you get there because everything’s distorted and whack–speed-bumps become cliffs and the little nuggets of interesting work you sprinkle throughout your day lose their luster. But the worst part is that it’s actually pretty hard to tell when you’re there.  I only realized I wasn’t in a great spot recently, and had troubles seeing a way out.

Lisa, my amazing wife and co-founder, really helped with the insight that gratitude is really what will get you out of dark spots.  Gratitude for family, for the people who throw their lot in with yours, for the opportunity to even try, for health, and even a warm breakfast and a colorful sunrise (fingers crossed).  And so I’m trying that and it’s really working.

 

 

 

 

0 comments on “Eulogy for the Old-Fashioned: Things We’ve Innovated Out Of Existence”

Eulogy for the Old-Fashioned: Things We’ve Innovated Out Of Existence

As a kid, I remember having my mom drop me off at the library so I could rummage through the card catalog. I still have warm-and-fuzzy nostalgic feelings about spending hours pulling books off the shelves, checking the indexes, and finding exactly the pieces of information I needed. It’s a nice memory, but would I trade away the Internet to get another chance at flipping through musty drawers of tiny typewritten cards? No way. You’d have to be bonkers to go backwards and do research like that. I’d rather sit at home in my pajamas and access hundreds of sources online in seconds, thanks very much.

Innovation is a funny thing. We get so accustomed to doing something one way, that it never occurs to us that it could be different. Better. Think about all of the things we used to consider perfectly fine until we figured out a better way:

  • Driving to the store to rent a movie (RIP, Blockbuster)
  • Placing a personal ad in the newspaper
  • Pulling over to make call from a pay phone
  • Planning a route using a tri-fold city map
  • Sending a fax
  • Looking numbers up in the Yellow Pages
  • Listening to music on a Walkman
  • Checking out what’s on tonight in the TV Guide
  • Using a typewriter with a bottle of Wite Out handy
  • Checking spelling using a dictionary
  • Looking facts up in an encyclopedia
  • Keeping business contacts in a Rolodex
  • Calling the theater for showtimes
  • Making a mixtape

At one point, someone asked: Why isn’t there a better way? Then they changed the game.

That’s what we did for the cloud at Sunshower.io.

People used to think it was okay to be surprised by their cloud bill, or to spend hours, sometimes days, sometimes months, deploying applications. We used to find it totally acceptable to ask developers to become experts in how to deploy their software, while still … you know … finding the time to actually write said software. Not anymore. Sunshower.io has all the tools you need to work with the cloud faster, simpler, and more efficiently than ever before.

Why take a boat across the ocean when you could fly? You have stuff to do, deadlines to meet. Check out our beta on DigitalOcean to see how we can show you a better way.

0 comments on “Github Pages with TLS and a Backend”

Github Pages with TLS and a Backend

Blogging consistently is hard, but we’re redoubling our efforts to get content out semi-regularly, even if it’s just to post something simple and (hopefully) helpful. To that end, I’d like to discuss setting up Github pages with a backend.

The Problem

 

Github.com allows you to host static content via its pages feature.  This is fantastic because it makes it trivial to create, deploy, and update a website.  This is how https://sunshower.io is hosted.

But what if you wanted to interact with, say, a database, to track signups?  Furthermore, what if you wanted to do it all over TLS?  This tutorial presumes that your registrar is AWS and your DNS is configured through Route53.

 

Set up Github DNS Alias Records For Github Pages

This one’s easy: In your Route53 Hosted Zone, create an A record that points to Github Page’s DNS servers:

>185.199.110.153

> 185.199.109.153

> 185.199.108.153

> 185.199.111.153

 

 

Then, check in a file in your pages repository under /docs called CNAME containing your DNS name (e.g. sunshower.io)

 

Push that sucker to master and you should have a bouncing baby site!

 

Publish your backend with the correct CORS Preflights

We pretty much just have a plugin for Sunshower.io that registers unactivated users.  Create an EC2 webserver/Lambda function/whatever to handle your requests.  The thing you have to note here is that your backend will have to support preflight requests.  A preflight request is an OPTIONS request that your server understands, and responds with the set of cross-origin resource sharing (CORS​ ) that your backend understands.

This is because your page, hosted at a Github IP, will be making requests to Amazon IPs, even though both are subdomains beneath your top-level domain.  For a JAX-RS service at, say, https://mysite.com:8443/myservice, you will need two methods:

 

@Path("myservice")
@Produces({
MediaType.APPLICATION_JSON,
MediaType.APPLICATION_XML,
})
@Consumes({
MediaType.APPLICATION_JSON,
MediaType.APPLICATION_XML,
})
public interface SignupEndpoint {

@POST
RegistrationConfirmationElement signup(RegistrationRequestElement request);
@OPTIONS
Response getOptions();
}

Note that there must be an @OPTIONS method for each actual conversation method that you want to interact with (e.g. the @POST method here).  What will happen is that a preflight will be made to the same path as the request, and the server will respond with whether that request is allowed.  You can widen the scope of @OPTIONS responses, but you should have a pretty good reason for doing so.

 

The actual @OPTIONS method will look something like:


@Override
public Response getOptions() {
return Response.status(Response.Status.OK)
.allow("POST")
.header("Access-Control-Allow-Origin", "*")
.header("Access-Control-Allow-Methods", "POST, OPTIONS")
.header("Access-Control-Max-Age", 1000)
.header("Access-Control-Allow-Headers", "origin, x-csrftoken, content-type, accept")
.build();
}

where the allow value and Access-Control-Allow-Methods values align with the request type of the actual backend methods.

 

Set up a SSL-enabled ELB

The first thing to do here is to create a certificate using AWS’s wonderful Certificate Manager Service.

Request a certificate by navigating to Certificate Manager > Request a Certificate in the AWS Management Console.  Request a public certificate, and then request it for the fully-qualified name that you want your backend to appear under (e.g. backend.sunshower.io).  If you have access to any of the follow e-mail addresses at your domain:

  • administrator@your_domain_name
  • hostmaster@your_domain_name
  • postmaster@your_domain_name
  • webmaster@your_domain_name
  • admin@your_domain_name

then select e-mail verification, otherwise select DNS verification and proceed according to the instructions provided by AWS.

 

Once you’ve verified your certificate, create an elastic load balancer on whatever availability zones your backend spans.  If you only have one instance in one availability zone (shame shame!), add that availability zone first.  Create a listener targeting the port that your actual backend is listening on, and add a security group with an ingress port that corresponds to the port that you want your public-facing backend to listen on (for instance, if you want your backend to respond to requests to https://backend.sunshower.io, configure your ingress to be 443.

From there, configure a target that points to your actual backend. If your backend is hosted on EC2 instances, select the instance type for the target, otherwise select ip.  Reference the IP/instances of your backend and create the ELB.

 

Configure a DNS A Record for your ELB

The last thing we need to do is create an A Record that points to your ELB.  If, previously, you requested a TLS certificate for backend.mysite.com, you’ll want to create an A-record whose name is backend, alias=true, with an alias target that is the ELB you created in the previous step.  Save that sucker and you are good to go!

 

 

 

0 comments on “Announcing Sunshower.io Preview!”

Announcing Sunshower.io Preview!

We’re thrilled to announce a preview launch of Sunshower.io. I’d like to take a little time to explain what we do!

Beautifully Simple Multicloud Management

The first thing we do is provide a simple, unified interface for managing your public clouds. This means that you provide some read-only access to your cloud, which we store securely in our vault, and then we go discover whatever infrastructure is in your cloud(s) and manage and organize it for you.

Let me step through a quick example:

Discover your Resources (aka “Systems”)

The first thing we need to do is to discover your resources. Upon logging into Sunshower.io, you’ll be presented with the System Discovery Wizard. A System (i.e. Weather System) is the set of all infrastructure associated with a set of cloud accounts. So, if you have:

  • 1 Azure Scale Set with 4 active members that is your development cluster (azure-dev)
  • 1 Azure Scale Set with 20 active members that is your production cluster (azure-prod)
  • 1 AWS Autoscaling Group with 10 active members that is your AWS dev cluster (aws-dev)
  • 1 AWS Autoscaling Group with 30 active members that is your AWS production cluster (aws-prod)

Then you will create a system with at least 2 credentials, one for AWS, the other for Azure.

wizard-accounts.PNG

You can add as many accounts from as many cloud providers as you want. Each of the cloud providers is implemented as a (relatively) simple plugin, and if you add a new plugin (e.g. Google Cloud), you’ll be able to add credentials for that cloud, too.

Once all your accounts have been added, we’ll go through and perform the actual discovery. Once that completes, you’ll be presented with a topological overview of your cloud infrastructure:

topological-overview

The group color is used in the topology view as the color between edges of nodes, and in the geography view to color connections between regions:

geography-view.PNG

And yes, you can totally spin the globe!

Use Your Groups

Grouping is pretty fundamental to Sunshower.io:

  • Access control is based on groups
  • Management operations can be performed on entire groups (yes, you can spin down every node in a cluster by stopping its group)
  • Deployments are based on groups

For instance, you can SSH into an individual machine or an entire group. It’s pretty typical to have a ton of identical machines, so executing the same series of commands produces identical output from each machine. We de-duplicate the output and provide you with the results. Just store your private key in our vault (the actual key is stored in the excellent HashiCorp Vault). But, hey, tailing logs across a bunch of machines has never been so easy!

ssh

Visual Deployments (aka “Strata”)

One feature that we’re really excited about is visual modeling of deployments. Basically, you start off with a series of commands (e.g. shell commands), and you compose them together:

visual-modeling

From there, you can select a deployer format (e.g. Docker or Packer or even just the userdata section of an AMI, whatever you have plugins installed for) and viola! You have a deployment that you can share with coworkers, publish to everyone, or share with a specific group. For instance, you might create a Stratus that

  • Installs Java
  • Installs NodeJS
  • Installs Gulp

And you can generate a Dockerfile for it, a Packer file, an Azure Image, or an AMI without changing a thing!

Visual Infrastructure Modeling for Systems

But let’s say you don’t have any existing infrastructure and you want to create some. Now, you can log into your various cloud providers’ consoles and spin up whatever you need, but what if you want to create some infrastructure and try it out across clouds? Enter our visual infrastructure modeling for Systems. You can quickly model your infrastructure and deploy it out to any supported cloud (below is the cluster structure for Sunshower.io’s deployment)

system-designer.png

You can also export the model to a variety of provisioners like AWS CloudFormation, Azure Resource Manager, or Hashicorp Terraform. We’re currently figuring out what generating Kubernetes manifests looks like, but you’ll be able to do that soon too.

Finally, Anvil for Optimization

All of the data that we collect about your infrastructure we use to build a model of your tasks. If you think about purchased infrastructure as a shipping container, then it makes sense to purchase the smallest shipping container that can fit all of your packages. Anvil extends this analogy by allowing you to define new dimensions for your packages (think 5 or more), and we’ll figure out the smallest shipping container with those dimensions possible across any infrastructure for which there’s an infrastructure plugin. For instance, here’s an example of us spinning up a suboptimal configuration of resources and running Anvil on it:

anvil.png

It yields a much more compact (dense) configuration for your infrastructure. In fact, it typically yields an optimal configuration. You can even configure it to model packages based off of their greatest historical dimensions (like peak hours) so that you’ll never under-provision again, even while saving a substantial amount on your infrastructure.

Conclusion

Thanks for sticking around! I wanted to provide a list of Sunshower.io’s current features to give everyone a better idea as to how it’s used and what it can do for you. Many people will only need one or two of the features, and we’d like to get some feedback as to which might be the most valuable for your organization so that we can get them to you ASAP.