pea

NStack | London, UK | Full time | Onsite | Functional Developers

We’re a building a "Cloud OS" for composable microservices using a mixture of Haskell and Linux systems technology (including containers, systemd, dbus), with some typed DSLs, systems code, and distributed systems thrown in. We want developers to spend more time writing core business-logic vs. writing infrastructure, and are using lessons from building programming languages and operating systems to accomplish this.

We’re looking for talented programmers -- preferably with some knowledge of typed functional languages and *NIX systems programming -- to join our small tech team to make this a reality. It’s a challenging role, working on hard problems, but the chance to work with a top technical team and shape a company and product from an early stage.

We’re funded by top-tier infrastructure investors from the West Coast, and the founders are both technical and ex-YC / academia. Salaries are competitive and include generous stock options. EU applicants welcome (other visas potentially possible), although roles are onsite only.

We’re looking at a range of positions and experience levels - whether you’ve just left uni or been hacking for 20 years, if you’re interested please get in touch. Any questions please comment, DM, or reach out via jobs@nstack.com or http://nstack.com/careers. Cheers!

Great article. Another good way we've had this explained is: if someone is in a burning building, you are the option of jumping out of the window.. There may be a 95% chance they will die, but they're in so much pain that they'll make the jump (even though they normally never would).

Do you think this is more geared for entry strategy (getting the tip of the spear in)? In an ideal world, you could find something where building a small quantum converges with solving this degree of pain.. though of course the stars do not always align that easily...

Yes, layering is somewhat of a hack to get around the fact that most OS package managers are mutable. IMO nix / guix have a much better approach here.

StackHut | London | Full Time | ONSITE

We’re a London-based startup working on a microservices-based “CloudOS” using a mixture of OCaml, Linux containers, and Erlang/Elixir - with some DSLs, systems code, and distributed systems thrown in. We want developers to spend more time writing core business-logic and less time thinking about infrastructure.

We’re looking for our first technical hires, who will be working with us to design and implement the core platform that will make this a reality. We have a MVP in Python (https://github.com/StackHut/stackhut); it gives a feel for what we’re trying to build, although is only a start.

We’re implementing this in OCaml, and are looking for talented functional programmers (OCaml, Haskell, F#, Scala, etc.) preferably with some knowledge of Linux/Unix systems programming. It’s a challenging role, working on hard problems, but the chance to build and manage a technical team and shape a company and product from the get-go.

We’re funded by top-tier infrastructure investors from the West Coast, and the founders are highly-technical and ex-YC / PhD. Salaries are competitive and include stock options.

Any questions please comment, reach out on email (jobs at stackhut dot com) or at https://stackhut.com/#/careers. Cheers!

Haha you're right. I love flock of birds analogy.. and thanks for the mention!

We've also been floating 'Software defined infrastructure', 'Software defined compute'. Sounds a bit like something out of a Gartner report though. It's really the idea of 'The developer doesn't think about infrastructure or writing server-logic. I only write business-logic, and I can run it anywhere.'

vs Lambda, we focused on the big pain-points: 1. Lock-in, lack of agnosticism. You can run StackHut wherever (and on-top of k8s, mesos soon). Lambda can't even be run on your local machine for dev. 2. Inability to do most of the stuff you do actually do on servers. With StackHut, you can define your stack completely, so if you want ubuntu with ghostscript and a bunch of weird binaries copied in.. go for it! 3. Built for RPC from the ground-up (dynamically mapping functions between languages so you can call your Python functions in JavaScript etc.)

We really are seeing infrastructure moving to a more open, agnostic world. AWS in 2015 is kind of the Windows 95 of infrastructure. Might be a bit of a stretch, but we see the cloud primitives of compute, storage, db/cache become almost like the CPU, hard-disk, memory. There will be an orchestration platform on-top of that (k8s, mesos, etc.), which is sort of like a hypervisor. And then on that there will be OS-like things (like us!)

Hey Jake -- thanks for your feedback, that is really helpful.

We're going to add some better pricing. How would you like this to work?

- per month, flat rate, ups w/ usage - per request - per compute / storage

We really like the idea of only paying for the compute you actually use a la lambda; one of my gripes with Heroku was having to pay $x when the server was only in use for short bursts. Why should I pay for downtime?

That said, we've actually had many people say they would prefer per month, as it is more predictable and they are worried it could spiral out of control.

I would be super interested to hear your thoughts.

Great to see Lambda stepping up their serverless game. We're big fans of this approach and are hacking on something similar to this at StackHut[1], but:

* Mostly OSS to avoid lock-in

* Git integration

* Full stack specification (OS, dependencies, etc.)

* Python/ES6 support (Ruby and PHP coming)

* Client libs so you can call your functions 'natively' in other languages.

It would be awesome to hear what people would like us to build for them. Here is a blog-post on how to build a PDF -> image converter: http://blog.stackhut.com/it-was-meant-to-be/

[1] https://stackhut.com

Lack of git/versioning integration is pretty key and is one of the downsides of requiring deployment from the browser. We're hacking on something that solves this @ https://stackhut.com.

Hi Jake! Sorry you're having issues.

I'm presuming you're on Sky in the UK? They are currently blocking HTTPS on various CloudFlare endpoints (such as ours!) We're attempting to get this sorted ASAP. Let me know if this isn't the case!

Cheers -- Leo

Hey all! I'm one of the devs @ StackHut and am here to answer all and any questions/rants/ideas/feedback. Cheers!

Hey Stephen -- Honestly, it was just what I had more experience using; I always presumed Phantom is more consistent and malleable, albeit sometimes a pain to configure. You are definitely right on the simplicity aspect.

We're aiming to extend it past basic screenshotting -- is there any functionality you'd like to see? (moreover, are there any other services we could chuck on the platform that you'd like to see?)

Link to GH issues here, too: https://github.com/StackHut/phantomjs/issues

Absolutely, we're more concerned w/ use-cases vs. Docker itself. PhantomJS is a great tool, and we're using it to show off the platform which hosts this sort of stuff in the cloud (with Docker!). Would love to get some more feedback: leo@stackhut.com :)

Hey Duboff! Sorry to hear that -- what website were you trying to screenshot? Would love to try and fix your issue: you can reach me at leo@stackhut.com .

Hey all, I'm one of the developers, so if you've got any questions -- shoot away!

Yo! We're building this at https://stackhut.com . You can see what an example API looks like @ https://github.com/StackHut/pdf-tools . You `stackhut deploy` this and it pushes it to an endpoint you can call over JSON-RPC or HTTP. Would love to hear your feedback (or ping me at leo@stackhut.com if you want me to walk you through anything!)

This looks really interesting -- I think the abstraction of the server away from a bunch of development cases is gonna happen pretty quickly.

We're hacking on something really similar to this at https://stackhut.com, where we are building a platform for Microservices which are powered by Docker, can be run wherever through HTTP/JsonRPC, and are really simple to build/deploy. Think "Microservices as a service"... ;)

To give you an example, here is a task which converts PDFs to images: http://stackhut.com/#/services/pdf-tools, and here is the code powering it https://github.com/StackHut/pdf-tools which we `stackhut deploy`d.

We're about to open up the platform and would love to hear what, if you had a magic wand, you'd wish upon the product.

Hey, we're actually hacking on solving this exact problem at StackHut.com, which is a platform for containerised services that you can call immediately through HTTP. I think your sentiment is super-common: building microservices / container-enabled services and getting all the good stuff that comes with them is still too much of a learning curve for most devs. We're just about to push live the ability to add new services: would love to get your thoughts on what you'd like to see: leo@stackhut.com

Re services sharing, we are actually hacking on a database of useful containerized services which are hosted on Github and can be run anywhere through HTTP or JsonRPC. Product is super early, but would love your feedback on what you'd like to see: www.stackhut.com . Just about to push ability to submit your own.

I think the key thing is that users shouldn't have to have a knowledge of Sysops or Devops to be able to take advantage of the benefits of containers. Most developer we've spoken to don't have time to learn a completely new paradigm, they just want the benefits.

ECS is pretty exciting, but isn't the same level of abstraction accomplished with the GCE/Fleet/k8s? Even the Kubernetes or Fleet install process on EC2 lets you quickly forget about the actual boxes.

That was one of the best and most honest things I've read re realities of startups. Props and gl

Never is a strong word. I agree with you on the VC front; but talent-front, I am so blown away w/ what London has to offer. Plus excellent schemes like Entrepreneur First are really changing stuff.

But the attitudes of investors is lacking massively: Aaron Harris tweeted that "When reading YC apps, the most important question isn't "Why could this fail?" but "How could this be incredible?"" -- this sentiment needs to seep into the minds here, who seem more focused on risk aversion than optimising for upside.

I hope this is the 'easy' bit to change (I'm not sure). My gut says it's an old guard that will eventually be replaced.

We used Scala for major projects; love the language, hate the infrastructure / documentation / frameworks / sbt / attitudes of many in the community. I believe this is a pretty common sentiment.

Hey, great questions, and thanks for the feedback. I agree with you re the 'many projects at once' sentiment. Let me see if I can clarify:

We can charge less because because we have standardised the process with software.

When a user leaves feedback on your website with TalkToUsers, the feedback comprises a screenshot, the textual content of the feedback, and the browser/user information.

We run some analysis on your feedback over a period, let's say a month: where people clicked, certain analytics, sentiment. This includes lots of derived quantitative information (i.e. 10 other people clicked on this div and left feedback). This bunch of data is sent to the UX team when your report is due.

The deliverable to the UX team is standardised, which means they can more quickly consume it. They read the derived data, and go through the screenshots. They use their experience to make qualitative judgment: 'Hey, these users aren't happy because of x, y, z. This came up in the analytics, and now someone is complaining about it'. After digesting this, they make an argument for what should come next. They enter their thoughts into the dashboard, and a report is created with the data, and they move onto the next one.

So, it takes them a lot shorter period of time to digest the data than alternative solutions, because the process has been streamlined: they are a part of what is essentially still a system driven by software, not people. Their input is vital and could not be done by a machine, but the 'operations' side of things has been automated.

For the reliability, it means that if one of our clients reaches out to us, someone in the UX team will be there and can offer some on-demand insights. It's a bit like having lots of smaller Heroku instances, vs. one big AWS one.

Does this answer your question? This is a pretty new service, so I'd love to get any more thoughts.

Thanks again.

I'm the author of the post, and I'd be happy to answer any questions anyone may have here. Cheers!

Not what you're looking for exactly, but you could settle for using Jade? https://github.com/duncanbeevers/jade-react

Is there a possibility that this will have a positive effect of a) pushing the issue to the forefront (because it affects everyone) where it can be easily disputed in its current form; b) making services like Tor / VPNs a necessity for regular people and thus moving everyone towards a safer internet not governed by states? This has already happened with the block of thepiratebay: regular people have been pushed into a position of regularly using VPNs.

Say Cameron get this passed. Technically it is unfeasible because they can't realistically ban foreign companies from using encryption, and because some of the protocols are (for the sake of argument) unbreakable. So if you want to stay anonymous, you still can, and more people will. Furthermore, the privacy argument goes mainstream when it is WhatsApp / Google vs. the UK government, with regular people suffering immediate consequences, vs. a bunch of programmers / cypherpunks. I can't see how this would be a positive for the government in any way.

Yup we use html2canvas with some CORS busting stuff for cross-site images for screenshotting. If you've got any more questions re our tech, reach out to me at leo@kivo.com and I'll answer them!

This is a really good point -- thanks. A few people have mentioned this. We're working on a demo dashboard so you can see what it looks like. Cheers for your feedback.

Hey,

Yeah I'm going to make some changes to make it more visible (I agree white on white isn't immediately obvious :) ). Thanks for your feedback.

Awesome! I've pinged you an email, so reach out whenever if I can help in any way.

Hey, I completely agree that support for mobile is currently lack-lustre. We will a) try and make this more evident on the home page, and b) disable on mobile for the timebeing if the experience is below par. Tomorrow we're going to start hacking something together to make it better.

Would love to hear your input, so feel free to ping me on leo@kivo.com.