I recently had a colleague send me an article entitled Microservices, Please don’t in which the author identifies several “falacies” that are surrounding the microservices craze. I don’t take issue with the topic or even any of the “falacies” the author outlines in the article. What I do take issue with is the (I assume) intentional mis-titling of the article, which misleads the user into thinking the author is going to present convincing reasons not to use microservices. Instead, the article points out common cultural misconceptions about how microservices will solve all their problems and then vaguely sums up with “[before you use microservices, simply understand] the domain you’re working in…”.
The article is no better than click bait really, which I won’t bother to rant about as I’m sure others have done so.
My response to my colleage:
The article seems to talk more about cultural problems than engineering. Complexity is complexity, regardless of your architecture, either approach can be taken to the extreme (to dire consequence). This kind of rhetoric is akin to “PHP, please don’t”. PHP can be wielded as wonderfully or terribly as any other language. It’s not the tool or pattern that is as important as the team that is wielding it.
Discipline
I guess what I really wanted to write about in this post was the topic of discpline, or the lack thereof. The article speaks to a lack of discipline more than an engineering problem, just as someone criticizing the use of PHP is really pointing out their inability to use the language effectively, not because of a lack of features, but because of a lack of discipline.
Use microservices or don’t. Use the monolith or don’t. It doesn’t really matter. What does matter is that your team understands the approch they’re taking and the tools they’re using, through debate, experimentation, and failure. There is no “one true way”. There is no “one true light”. Put your teams and their conversations over your tools and your patterns.
Did you fail? Good. Talk about it, don’t blame. I don’t know of any organization where success is guaranteed every time. But every organization I know that banks all their success on their first (and only) implementation fails, and subsequently creates a culture of blame, either for the “old guard” developers, past employees, or someone else on the team.
Set yourself up for success by practicing failure
Discuss, argue, agree, experiment, repeat. Do this with discipline. This is the only way you’re going to find the “magic recipe” that actually works for your organization, be it microservices, or the monolith.
This is more of a note to self as much as a blog post, as well as I would like to get blogging again.
Lambda integration vs. Lambda-Proxy
We just went through the process of setting up an AWS API proxy for lambda again today, and API Gateway seems to have changed a lot over the last little bit.
One of the new Integration Request options is “Lambda Proxy” which basically just sends the full request to Lambda (including the URL info) as opposed to just invoking the function.
if key isNone: log.warn('Creating new key for {}'.format(site_name)) key = bucket.new_key('{}/endpoint.json'.format(site_name)) key.content_type = 'application/json'
At work we’ve been looking for a good solution to consolidate our service layer. We have around 30-40 backing services for our application and web tiers. The problem with the current setup is that they’re deployed all over the place; some in EC2-land, and some are colocated, and they’re in various languages.
We’re working on consolidating our services into a consolidated architecture:
service stack (Python/WSGI)
load balancer
service cache
service proxy
…or something like that. I’m primarily interested in the first item today: service stack.
The problem with EC2
We absolutely love Amazon Web Services. Their services remove a lot of the headache from our day-to-day life. However, EC2 instances get pricey, especially when deploying a lot of services. Even if we put all of our services on their own micro instances (which isn’t a great idea) the hard cost is pretty clear… let’s assume 50 services at today’s prices:
50 t1.micro instances x ~$14/month = $700/month
This doesn’t seem like an astounding number, but to be fair, this probably isn’t an accurate estimate; we’re still forgetting high availability and load balancing, as well as snapshots. Assuming a t1.micro is a great option for all services, let’s factor in the new costs:
(50 t1.micro instances x 2 availability zones x $14/month) + (50 elastic load balancers x $14/month) = $2100/month
Having a high availability setup is starting to add up a bit, and there are still additional costs for EBS, snapshots, S3 (if you’re using it), and data transfer.
The case for Deis
Deis is a platform-as-a-service (Paas) much like Heroku or Elastic Beanstalk. There are a few other open source solutions out there like Flynn.io (which is at the time of writing still in alpha) and dokku. Dokku will only run on a single instance, which doesn’t make it quite as appealing as Deis.
The whole idea behind Deis is that you can simple git push your application code to the cluster controller, and the platform will take care of the rest, including providing the hostname and options to scale. The solution is based on Docker which makes it extra appealing.
Enter AWS EC2
There is a contrib setup for EC2 in the source repository, and it looks like it should work out of the box. It doesn’t currently appear to have support for AWS VPC just yet, but it is just using CloudFormation stacks behind the scenes, so the configuration should be pretty straight forward. Now, I don’t know about anyone else, but CloudFormation templates (example make my brain hurt. AWS’s documentation is pretty clear for the most part, but sometimes it seems like you need a very specific configuration in about 6 different places for something to work. VPC is very much like this.
Fortunately, someone has already tackled this and there is a pull request open to merge it into deis trunk. The pull request effectively adds a couple configuration values that should allow deis to operate in a VPC. Primarily, there are a couple environment variables you need to set before provisioning the cluster:
I did run into one problem with this, however, when I specified the environment variables, I found my CloudFormation stack creation was failing (you can find this in your AWS console under the CloudFormation section, click on a stack, and select the ‘Events’ tab below). The error I was getting was related to the VPC and AutoScalingGroup not being created in the same availability zone, so I had to tweak the CloudFormation template under the Resources:CoreOSServerAutoScale:Properties:AvailabilityZones key to reflect my AZ (namely us-west-2b).
The IGW
Another problem I ran into (that had nothing to do with Deis) was I was deploying to an availability zone that didn’t actually have access to the public internet (no gateway/nat). This manifested as an error when trying to make run the cluster:
1
Failed creating job deis-registry.service: 501: All the given peers are not reachable (Tried to connect to each peer twice and failed) [0]
Once I got into the proper availability zone, the problem went away.
make run
I ran into some more issues when I finally got make run-ning…first the “activation” part of it took a really long time, like 15 minutes. I finally got this error:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
af:deis aaronfay$ make run fleetctl --strict-host-key-checking=false submit registry/systemd/deis-registry.service logger/systemd/deis-logger.service cache/systemd/deis-cache.service database/systemd/deis-database.service Starting 1 router(s)... Job deis-router.1.service scheduled to 22e48bb9.../10.0.14.17 Starting Deis! Deis will be functional once all services are reported as running... fleetctl --strict-host-key-checking=false start registry/systemd/deis-registry.service logger/systemd/deis-logger.service cache/systemd/deis-cache.service database/systemd/deis-database.service Job deis-registry.service scheduled to 4cb60f67.../10.0.14.16 Job deis-logger.service scheduled to 22e48bb9.../10.0.14.17 Job deis-database.service scheduled to 4cb60f67.../10.0.14.16 Job deis-cache.service scheduled to bc34904c.../10.0.14.13 Waiting for deis-registry to start (this can take some time)... Failed initializing SSH client: Timed out while initiating SSH connection Status: Failed initializing SSH client: Timed out while initiating SSH connection Failed initializing SSH client: Timed out while initiating SSH connection One or more services failed! Check which services by running 'make status' You can get detailed output with 'fleetctl status deis-servicename.service' This usually indicates an error with Deis - please open an issue on GitHub or ask for help in IRC
One of the admins on the IRC channel for #deis mentioned that you can make run again with no problems, however after several runs I still couldn’t get the command to complete free from errors. make status pointed out the issue with the controller:
1 2 3 4 5 6 7 8 9
af:deis aaronfay$ make status fleetctl --strict-host-key-checking=false list-units UNIT LOAD ACTIVE SUB DESC MACHINE deis-cache.service loaded active running deis-cache bc34904c.../10.0.14.13 deis-controller.service loaded failed failed deis-controller 22e48bb9.../10.0.14.17 deis-database.service loaded active running deis-database 4cb60f67.../10.0.14.16 deis-logger.service loaded active running deis-logger 22e48bb9.../10.0.14.17 deis-registry.service loaded active running deis-registry 4cb60f67.../10.0.14.16 deis-router.1.service loaded active running deis-router 22e48bb9.../10.0.14.17
failed hey? The same admin on the channel recommended fleetctl start deis-controller although I think I’m using an older version of fleetctl (0.2.0?) and I had to actually run fleetctl start deis-controller.service. That appears to have worked:
1 2 3 4 5 6 7 8 9 10 11 12
af:deis aaronfay$ fleetctl start deis-controller.service Job deis-controller.service scheduled to 22e48bb9.../10.0.14.17
af:deis aaronfay$ make status fleetctl --strict-host-key-checking=false list-units UNIT LOAD ACTIVE SUB DESC MACHINE deis-cache.service loaded active running deis-cache bc34904c.../10.0.14.13 deis-controller.service loaded active running deis-controller 22e48bb9.../10.0.14.17 deis-database.service loaded active running deis-database 4cb60f67.../10.0.14.16 deis-logger.service loaded active running deis-logger 22e48bb9.../10.0.14.17 deis-registry.service loaded active running deis-registry 4cb60f67.../10.0.14.16 deis-router.1.service loaded active running deis-router 22e48bb9.../10.0.14.17
So far so good
I now have Deis running in the VPC, well, the first bits anyway. I will update with the second part which includes DNS configuration, initializing a cluster, and deploying an app.
I have need to migrate some sqlite3 databases to mysql for a couple django-cms projects at work. Typically in the past I’ve used fixtures in Django to get this done, but I usually have to align the planets and concoct the elixir of life to get the fixtures to migrate properly. It usually has to do with foreign key errors something. This is something that should just be easy, but in my experience with Django, it never is.
defmain(): print"SET sql_mode='NO_BACKSLASH_ESCAPES';" for line in sys.stdin: processLine(line)
defprocessLine(line): if ( line.startswith("PRAGMA") or line.startswith("BEGIN TRANSACTION;") or line.startswith("COMMIT;") or line.startswith("DELETE FROM sqlite_sequence;") or line.startswith("INSERT INTO \"sqlite_sequence\"") ): return line = line.replace("AUTOINCREMENT", "AUTO_INCREMENT") line = line.replace("DEFAULT 't'", "DEFAULT '1'") line = line.replace("DEFAULT 'f'", "DEFAULT '0'") line = line.replace(",'t'", ",'1'") line = line.replace(",'f'", ",'0'") in_string = False newLine = '' for c in line: ifnot in_string: if c == "'": in_string = True elif c == '"': newLine = newLine + '`' continue elif c == "'": in_string = False newLine = newLine + c print newLine
This post is a bit of a ‘note to self’. I am tinkering with Vagrant boxes today trying to flesh out some ansible and I need to get the boxes to talk to each other locally. I know about the vagrant multi-machine setup, but I was already partly committed to having 2 individual boxes set up before I discovered it.
So, the trick is, set the network configuration in your Vagrantfile to “private_network”:
With the IPs set differently it seems to work, and the host is accessible as well. Note that my host subnet is 192.168.1.x. Probably not the right way, but it works for now.
Just a super-geeky post. I was using node-wheat for blogging for a while because it was super-easy to set up, and would just operate off a git repo. Pretty cool, but I never got the time to add some of the features I wanted, and it doesn’t appear to be maintained any more, despite it’s coolness.
Anyway, I just converted the blog to hexo which is very similar (uses markdown as well) but has some super-sweet features, namely gists, jsfiddle integration, and some other fun stuff. On top, it generates all the static files so the site is super-fast.
pm2: kickass process monitor for node, think supervisor if you’re from python-land but with some neat features.
That’s it. Super-simple setup, easy to maintain, updates automatically, and no plugins to get hacked and create spam :) Hopefully with some new shiny I will make more time to blog about current challenges.
One of the things I enjoy about building projects with nodejs is using npm, specifically the devDependencies part of package.json. This allows you to have one set of dependencies that are installed in production, but have extra dependencies installed for development, such as test libraries, deploy tools, etc. To get the development dependencies with npm you run:
1
$ npm intall --dev
how about pip
It turns out if you are using pip 1.2 or newer, you can now do the same thing in your setup.py file for Python packages.
“…why package two modules together if you can simply break them apart into two kernels of functionality which are codependent?””
Problem
One of the core sore points for me right now is the existence of “common” libraries in our work. It’s common to have a piece of code that is needed in the current project, but doesn’t particularly belong there. The approach (I often see) is to create said “common” library and deploy that with all of the projects that need the code. The major resistance to putting this in an individual package is probably the overhead of maintaining a separate repository for the individual code, along with the pull/commit/push/tag/release cycle that comes with it to make changes to a potentially developing module. So in the end, we end up with the “common” library.
The problem with is many-fold though:
dependency chains are not explicit,
the “common” library grows over time,
the same library becomes disorganized,
it’s not clear later on how to break things out because it’s not clear what projects are using what parts of the library,
Back to the node.js philosophy, if you’ve ever used npm before, you know that there are tons and tons of modules available for node (as an interesting sidenode, npmjs module counts are growing by 94 modules/day at the time of writing [link]). The recommended approach is to keep modules small, and publish them independently so they can be used explicitly across applications. James Halliday writes about this approach on his blog.
I’ve also recently set up a mypi private package index for our work, so we can start moving towards small, reusable python packages. I’ve also looked at djangopypi and djangopypi2, the latter being a bootstrap-converted fork of the former. Both these projects seem to add a little more functionality around users management, and of course they’re built on Django, which means you get the nice Django admin at the same time. I haven’t had time to do a full comparison, that will have to come later. For the time being, mypi seems to do the trick nicely.
Where setuptools falls apart
Turns out, using pip, you can just specify a custom index in your ~/.pip/pip.conf and then pip install <packagename> and you’re good to go. That’s fine for installing one-off modules, however, automating the entire depenedency installation process wasn’t obvious at first.
Setuptools fail
My scenario had 2 projects, Project A and Project B. Project A relies on custom packages in my mypi index, and is published to the package also. Project B has a single dependency on Project A. Using setuptoolspython setup.py install would find Project A in the private package index (via dependency_links), but none of Project A‘s custom index dependencies were being found, despite having specified the dependency_links in that project.
“Internally, pip uses the setuptools package, and the pkg_resources module, which are available from the project, Setuptools.”
Turns out pip spits out the setuptools configuration (whatever you have in your setup.py) into a /<project-name>.egg-info/ folder, includingdependency_links.
To get the pip equivalent of python setup.py develop just run:
1 2
# -e means 'edit' $ pip install -e .
To get the same for python setup.py install run:
1
$ pip install .
The super-cool thing about this is that dependency_links no longer need to be set in the setup.py files as pip will use the custom index set up in the ~/.pip/pip.conf file.
Done and done
I think this solution will solve some of the problem of having all the git/Github overhead involved in releases. With a simple fab setup, release candidates and formal releases can be incremented and deployed in a way that feels a little more clean and independent of the git workflow, while still maintaining source control. I’m hoping it will promote users to push modules early in a ‘sharable’ way to the private index so they can be easily installed for others. All in all, it feels cleaner to do it this way for me.
Hope that helps someone else down the road. Now we have a nice private registry for our python packages, and an easy way to automate their installation.
Note It appears that djangopypi is actually maintained by Disqus, that may make it a good reason to use the project, as it will probably be maintained for a longer period. I will explore that option and write up a comparison later.