Wednesday, August 19, 2015

Go as a client side language

I was talking to a colleague of mine and we were both expressing the same feeling towards Javascript: bleah.

As I was going home, I've noticed this "piece of joy" on Reddit https://www.reddit.com/r/golang/comments/3hlfo6/do_you_guys_think_go_will_explode_the_same_way/ and I got frustrated with the answers there. One of them frustrated me in particular: https://www.reddit.com/r/golang/comments/3hlfo6/do_you_guys_think_go_will_explode_the_same_way/cu8c7rb (in case it disappears it says: "No because go isn't a language used by the web browsers.").

Leaving aside the lack of technical understanding that the user displayed, it got me thinking: what would be the reason that would get in the way of Go being used browser (client) side? Turns out that I can't find any, or at least my lack of technical understanding says: none.

How would it work?

There are two major approaches on this: ship the code or ship the compiled module.

I've tweeted the idea of creating a runtime for browsers and someone said: yeah but in this case you'll end up just like NaCL did. As I actually didn't knew why NaCL didn't took off, I've searched for NaCL on Wikipedia and discovered that Mozilla made a stupid decision to focus on HTML (Picard facepalm).

So, it's possible that Mozilla will again say no to this because in their stupidity they'll focus on HTML again, or maybe they'll say that they now have Rust and they should build a runtime on that, it's their language after all, no?

And this is such a pity as Go really is a beautiful language and the use of channels for events and all the concurrency stuff would be a nice fit for the modern web.

Too bad we all can't play along and personal (and corporate) interests dictate the free web and how we, the developers, have to suffer from it.

Sunday, August 9, 2015

How AWS Lambda works - if I'd implement it

Disclaimer: I don't work at AWS or Amazon nor do I have access to any privileged information. This is purely an exercise of imagination, if Lambda actually works like this then yey me :)

AWS Lambda is a new toy from AWS which promises you that you won't have to care about infrastructure anymore when running code. It's the next level after BeanStalk and even AppEngine and the closest thing we have to a "Code As A Service" that we have to date.

Since AWS is pretty sure not to release anything about the inner most working of it anytime soon, everyone is up for guessing what's under the hood, so I asked myself: How would I implement it?

The description says:
AWS Lambda is a compute service that runs your code in response to events and automatically manages the compute resources for you, making it easy to build applications that respond quickly to new information. 
AWS Lambda starts running your code within milliseconds of an event such as an image upload, in-app activity, website click, or output from a connected device. 
You can also use AWS Lambda to create new back-end services where compute resources are automatically triggered based on custom requests. 
With AWS Lambda you pay only for the requests served and the compute time required to run your code. Billing is metered in increments of 100 milliseconds, making it cost-effective and easy to scale automatically from a few requests per day to thousands per second.
The developer in me is happy with this. I get to write code only, deployment is as simple as uploading a zip file to S3 and done, things run, people get their data, I don't manage the infrastructure and everyone's happy and sleeps at night.

The only thing that I have to worry about is getting my code to run as fast as possible, as the billing is done in increments of 100s of ms, and use as little amount of memory, that's being billed as well.

Can we make the specifications out for Lambda based on the information we have?

What we know about Lambda?
  • it runs in an isolated environment
  • it runs quickly in response to events
  • it scales in response to events
  • it has constraints for memory (which also controls how much CPU you get)
  • it has a timeout of 60 seconds for the function it runs
  • it has a "temporary" space you can use but you are not supposed to rely on it
  • you should not rely on the fact that subsequent requests will run on the same machine

What can we dig up about Lambda?
  • first run is a little bit slower
  • subsequent runs will be fast if they are in a within a certain interval
  • CloudWatch logs seems to indicate that it will favor reusing the existing instances vs spawning new ones regardless of the throughput levels if it scaled enough to accommodate for the throughput
  • it scales horizontally
  • it's between t2.micro and t2.small in terms of maximum memory (or t1.micro and m1.small if you prefer older instances types)

So where does this gets us?
Based on the above capabilities and requirements, if I were to implement Lambda over the AWS I'd use:
  • ECS
  • some smart container scheduler, tailored for the workload type that Lambda has
  • communication adapter: this one acts as a "translator" from the various input sources to RPC (or HTTP?) and back
    • definitely with ELB in front of it for mediating the traffic
    • SNS for anything that can react to events inside AWS
  • one dedicated container built for every function that you upload which packs the communication adapter
  • CloudWatch: monitoring is needed, no? No?

Lets look at the information we have from a different perspective.
Aside from the dedicated instances, Lambda potentially has the whole AWS infrastructure to run on.

It's not hard to imagine that even with probably an extremely intelligent scheduler for placing instances there are still empty "spots" in the infrastructure. Those spots means servers are not used to their maximum and given the above description for how to build Lambda, they would be perfect to run it as well.

Looking out on how the AWS rolls out the services, ECS and Lambda, I think it only goes forward into proving that they went for a similar approach described above.

What does it miss?
Lambda would be beautiful to put in front of medium or even large workloads with quick response times but there's a critical part missing. Due to the way it works, if you want to use persistent connections to RDS there's no way to do this yet. If I were to implement it, I would definitely have an AWS DB connection pool somewhere in the middle between Lambda and RDS (AWS if you read this, *wink* *wink*).

To sum it up:
I can totally build it from the building blocks AWS provides, as well as any other cloud provider. And I hope who had the idea to do it got a fat bonus for it as I didn't (had the idea before it). Lambda is also a good way for AWS to better utilize their hardware and for people who don't need a complicated backend to just care about the code.

I think this might be the future for small business or very young / incubation period startups or hackers and tinkerers who just want a quick way to make their code run over the web without headaches and I'm definitely going to use it pretty soon in production.

I'd be happy to hear what other people think, if someone digs this one up.

A thank you goes to +Onur for providing suggestions on how to improve the readability of my post: Thank you!

Reddit thread: https://www.reddit.com/r/aws/comments/3gih4a/how_aws_lambda_works_if_id_implement_it/
HackerNews: https://news.ycombinator.com/item?id=10037476
Tweet: https://twitter.com/dlsniper/status/630853292768251904

Monday, July 27, 2015

Find out the uptime of your Samsung SmartTV

Lately I've been playing around with some stuff, among which I've decided to see what's around me in my home network. Today I've stopped by my TV, which is a Samsung 6500 Series from 2013 (45" model). Turns out that it has some open ports...

PORT     STATE SERVICE
80/tcp   open  http
443/tcp  open  https
4443/tcp open  pharos
6000/tcp open  X11
7676/tcp open  imqbrokerd

Now, I've only had time to check out port 80... and this is how I've found out the uptime of my TV.

curl -I http://TvIP/

HTTP/1.1 404 Not Found
Content-Type: text/html
Content-Length: 345
Date: Thu, 01 Jan 1970 00:31:52 GMT
Server: Swift1.0

Turns out that the date is set to 0 (Unix timestamp ftw) every time the TV starts and the server starts with that and tadam.. this is how you get your TV uptime :)

In the weekend I plan to dedicate some time to my car, this should be fun :D

Saturday, July 25, 2015

Github is not my CV

The other week I've got a call from a person who said something about being a "professional headhunter", "recruitment professional", something something dark side, and the dialog was like this:

(the person) - hey, my name is "headhunter something something", I work for "dark side inc." and I'd like to tell you about a great opportunity for you. I've seen your github profile and I think you will be a good fit.
(me) - hi, no thanks, I'm happy with my career right now, have a nice day.

I seriously hate this. Really. Github is not my CV and it should never be.

Github, among many others, is a place where people collaborate on projects or release things they'd like others to use or give feedback for. My contributions to the community are done in the spare time that I have, in almost 99% of the cases, or because I encounter a bug while I'm at work so either I file a bug or a bug fix to the project that I'm using (yeah, Tapglue is awesome in this regard, I can actually fix something in the community if we use it and I can do it).

Many people do this in their own spare time as well. Granted, there are companies like Google or others which allow people to work on open-source projects directly and thus they are more visible, but hey, they actually get payed for that, it's not only because they are cool persons and want to give something back to the community (not saying that they aren't cool and al, you get the picture).

But seriously, I have a job, usually 9 to 18 (more often than not 10 to whenever something in the late evening) and sometimes I have enough time to do something useful for a project that I use or for the community so... Yeah, don't hire me based on that. Hire me because I'm a good engineer, hire me because I have quite a few years of experience in what I'm doing, hire me because I enjoy what I'm doing and I always try to best myself and finally, hire me because I've seen sh*t and I'll fix it faster and better than your average ninja superstar cowboy guru hipster that advertises himself/ herself as such. And if you decided that you want to hire me, after seeing my LinkedIn profile, and after I pass whatever tests / recruitment procedure you have, and you say: hey, he's a nice guy, we want him. Oh and look, he's also contributing to the community back, then yeah, that's cool, it's a bonus, not a feature, not a mandatory activity.

Why I rant? Because it's called Software Engineering, not Social Media monkey typing, ok? We are supposed to help the others automate things, making them better, improving their life and quality of life, supporting people that have disabilities with better, smarter, technology and overall do our small part of the contribution for advancing the humankind to the next stage. But because of the myth that "everyone can code", we've got hispsters and all those self-promoted ninjas and cowboys and whatever else they are who are not even related to what a Software Engineer is or should be. Please promote quality not quantity, pretty please.

Fragmentation on Android is hilarious

I was trying to create a new Android app today and using Android Studio (latest canary release, ofc).

Obviously in the process I've got to the platform targeting part. And then the shock came in.


Look at it... Seriously, look at it. There's more than 50% of the people who don't run on 4.4 or later. I mean c'mon, really?

I know forcing users to upgrade on mobile devices is hard, especially since the mobile manufactures don't really seem to care about existing users, security or otherwise getting latest version of the OS to their users (I guess it's not profitable, no?) But I seriously hope that Google can find a way to fix this sooner rather than later because it's getting hilarious at this point. Android M will be out soon-ish (September or close, right?) and by then there will be not two, not three but nine different versions if you want to target 100% of the platform and four versions in order to target about 50% of the users.

And people were moaning about fragmentation on desktop (Windows) just a few years ago when there were like 2-3 different versions only. 

As a last fun thing, HTC HD2 launched in ~2009 can run: Windows XP, Ubuntu MeeGo, Windows Phone 7, Android 5.0 (last I've checked) and I'm almost willing to bet it will run Android M as well. That's a six years phone who can run most of the OSes from out there proving that's in fact possible to have an updated phone if manufacturers would only care (oh and HD2 was meant for Windows 6.5, the community managed to do all the wonderful things I've just mentioned).