Less than a month ago I have attended an event by Amazon called “AWSome Day“. Not a boring event, that’s for sure, but surely designed to mirror the company image: clean, complex and thoroughly customer-oriented.
The presentation day was split in 2 parts, the first one being lighter, more business oriented while the second (after lunch) being more technically focused. Nevertheless, one must not forget a very important detail: if no price is charged for a product (e.g. it is offered for free or looks like it is) then you, the one at the receiving end, are the product:
Amazon offered the venue, the presentations, the lunch and the refreshments for free and then ran the up class equivalent of a shameless sales pitch.
The products covered in depth or by the hands-on demo during the presentation were:
-
Elastic Compute Cloud (EC2)
-
Simple Storage Service (S3)
-
Content Delivery Web Service (CloudFront)
-
Relational Database Service (Amazon RDS)
There were more products mentioned or barely touched:
Everything considered, it was a full day. The full presentation is available on SlideShare (link) for those that want to take another look. Many slides were skipped due to the time constraint as there seem to be even more AWS products described in there.
At the end of the day one must not oversee a couple of important details when thinking about The Cloud and Amazon Web Services in particular; AWS – as a product collection – is, feature and interface wise, a couple of years ahead of the competition. NB: yes, there is competition, there are multiple companies providing similar services, sometimes in a cheaper or in a most cost effective way than Amazon.
From my point of view AWS should be the way to go for:
-
Experiments, test deployments or temporary solutions;
-
Non-production environments with fluctuating lifetime and composition (e.g. for development and/or qa);
-
Handling unusually high loads for few days during the year (e.g. traffic peaks on Black Fridays or during the Christmas Sales);
-
Medium and long term data storage (backups).
If one has a fixed environment that will not change or scale in a significant manner for one year or more (e.g. a production-level website and/or a SaaS type of product), AWS may not actually be the only cost effective solution to look for.
Conclusion: if there is such event near you, go secure your seat! But don’t forget that you are actually being sold something.
Who likes interviews? Me neither. Well, depends…
If you get any of the following questions during an interview then either the interviewer did read this one or he’s getting info from the same sources as I am. Either way, let’s get one step forward.
Question 1:
Suppose you log into a node and find the following situation:
# ls -la /bin/chmod rw-r--r-- 1 root root 56032 ian 14 2015 /bin/chmod
Is it fixable?
… yes. Most of the time. Let’s remember how the executables are being started on Linux: with a system loader, ld-linux-something. Let’s check:
# ldd /bin/chmod linux-vdso.so.1 => (0x00007ffdf27fc000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb11a650000) /lib64/ld-linux-x86-64.so.2 (0x00007fb11aa15000)
OK, got it:
# /lib64/ld-linux-x86-64.so.2 /bin/chmod +x /bin/chmod
Fun, isn’t it? The follow up question obviously is “what if the loader’s rights are unproperly set” or something similar. The answer to that is that not all the filesystem issues are fixable with easy commands. One may even have to mount the file system on a different installation (e.g. from a Live CD or attach the virtual storage to another, “good” node) and fix things up from there.
DevOps: some people think it’s a hype, a sysadmin job redefined, other people believe it’s just another skill you get from some training or out of school. It’s neither. I personally would say it’s a combination of skills; you get some from school, other from formal training and the rest from the daily hands-on job.
Why is it not just some SysAdmin job redefined?
-
A “classical” SysAdmin does not use complex automation tools. His/her usual job is to go from one node to the other and set configurations, install software and fix things that do not work;
-
A normal SysAdmin job does not (usually) involve coding, apart from small scripts that run on individual nodes;
-
The “classical” SysAdmin (usually) deals with physical nodes and a good part of his/her daily job is fixing storage issues (rebuilding file systems, restoring from backups), debugging various hardware incompatibilities and applying patches.
Why do (serious, formal) coding skills matter for a DevOps?
The current industry trend is to express infrastructure through Code. You can currenty spawn entire environments (e.g. in AWS) with properly sized hardware configurations and services installed through Code only; this is possible with Automation tools like Chef. This is not about simple scripting skills but there are no complex algorithms either.
As I have just mentioned, DevOps is defined through Automation as the node interaction is no longer almost entirely manual. One now runs commands to multiple nodes at once and employs various automated monitoring tools that raise alarms and (sometimes) trigger tasks that do fix those issues, including, but not limited to, scaling resources or even adding new nodes to some cluster.
Who needs DevOps skills? I think that any organization that employs a large computing environment, large enough that scaling through classical SysAdmin operations is no longer feasible or cost-effective. Or, for that matter, any organization that intends to move its infrastructure to the Cloud. Being a new position that cannot be put in the same category with Devs, SysAdmins or QAs, there may be difficulties in filling up the job requirements, the career path or even deciding the compensation, but things are starting to change.
This was my introduction to the DevOps concept. Thank you for your read!