The heart of the Sunshower.io cloud management 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 a cloud management platform, we understand that 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.
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@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 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.
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.
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’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.
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. From cloud resource management to cloud cost optimization, we’re here to help your company succeed by demystifying cloud computing so you can focus on what matters — your business.
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 a cloud management platform like 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, AWS, EC2 management, or cloud cost 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.
Meet the 9 companies competing in Fort Collins Startup Week’s PitchNo.CO
BY APRIL BOHNERT, FEBRUARY 21, 2019
Fort Collins Startup Week kicks off on Monday and, for the second year in a row, LaunchNo.CO — a nonprofit dedicated to supporting startups and entrepreneurship in Northern Colorado — will be hosting its PitchNo.CO pitch competition.
This year’s competition, which takes place Feb. 26 through March 1 at Spaces coworking in Fort Collins, features nine companies from Larimer and Weld counties that will pitch their ideas in front of a panel of CEOs from companies like Boomtown and UpRamp.
We’ve taken a look at the startups competing this year to learn more about their products and how they’re hoping to transform industries from solar to fashion to cannabis — and a whole lot in between.
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. It’s cloud computing optimization unlike anything else out there? 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 compute 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 cloud usage plan to help with AWS cost optimization. The bottom line: Our AWS cost optimization 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!)
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 was a cloud management system 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 with cloud cost optimization.
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.
Testing UI components is one of the more difficult parts of QA. In Stratosphere (one of the key components of our cloud management platform), 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.
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.
Our project structure is pretty simple: we keep all our components and tests under a single directory, src:
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:
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:
Now, you can run your tests with npx jest:
firstname.lastname@example.org test /home/josiah/dev/src/github.com/sunshower/aurelia-aire/aire
Test Suites: 4 passed, 4 total
Tests: 12 passed, 12 total
Snapshots: 0 total
Ran all test suites.
Enabling support for complex DOM operations
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:
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!
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. The problems we’re solving are incredibly fascinating: AWS cost optimization, cloud resource management, and EC2 management are all issues I’m excited to be working on. But in the daily grind of solving those problems, 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.
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. We’re a cloud management platform that’s dedicated to offering better cloud resource management strategies and simple cloud cost optimization tools.
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 offer you a more innovative cloud management system.
When you’re spending your days (and nights) developing the best cloud management platform possible, blogging consistently is hard. That said, 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.
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:
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:
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:
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:
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!