For those who have been test driving the autoscale on the virtual machines scale sets… You probably have run into the situation where you wanted to go beyond the quickstart examples!
A quick tip on how to find out which Metrics are available for your autoscaling ;
So now you have the list of metrics which you can use to tweak the vmss-autoscale templates (for example ; https://github.com/Azure/azure-quickstart-templates/blob/master/201-vmss-ubuntu-autoscale/azuredeploy.json )
The latter versions of Adobe Acrobat Reader had an annoying pane in the right that everyone always closed down immediately to increase readability. Though next time you opened up a PDF, the pane would be back! All changes to the state of the application were saved, except for this one… Extremely annoying and a waste of precious time when you need to close down that pane everything single time!
So for those who are also annoyed by this, apply the following steps for permanent removal ;
- Close Acrobat Reader
- Browse to the program folder of Acrobat Reader and then go to “Acrobat Reader DC\Reader\AcroApp” and then your language code
- Delete the following files : AppCenter_R.aapp & Home.aapp & Viewer.aapp
- Start up Acrobat Reader
Developing a website… ; Open up “notepad++”, browse to your web server via FTP and edit the files. Then refresh to see the changes…
Sounds familiar? Probably… It’s a very straight forward and easy process. The downside however is that you have no tracking of your changes (Version Control) and that the process is pretty manual. So this becomes a problem when you aren’t the only one on the job or if something goes wrong.
So let’s step it up and introduce “version control”… Now we have an overview of all the revisions we made to our code and we are able to revert back to it. Yet suddenly, we need to do a lot more to get our code onto the web server. This brings us to the point where we want a kind of helper that does the “deployment” for us.
The basic process
- Local Development : The development will happen here. Have fun… When you (think you) are happy with what you have produced, you update the files via your version system.
- Source Repository : The source repository will contain all the versions of your code. Here you can configure it to send a notification to your deployment system whenever a new version has been introduced.
- Deployment System : The deployment system will query the source repository and retrieve the latest code. This code will be packaged, transmitted and deployed onto the target system(s).
- Target Systems : The systems that will actually host your code and deliver the (web) service!
Real Life Example?
- Create a private repository at BitBucket
- Pull/push the repository between BitBucket & your local SourceTree
- In GitHub, go to “Settings”, “Deployment Keys” and generate a key for your automation. Copy it to your clipboard…
- In DeployHQ, go to “Settings”, “General Settings” and copy to key into the “Public Key Authentication” textbox.
- In DeployHQ, go to “Settings”, “Servers & Group” and create a new server.
- In the same screen, Enable “Auto Deploy” and copy the url hook.
- Now go to “Settings” in GitHub, and then “Hooks”. Add a “POST” hook containing the url hook you just copied.
- Now every time you do a commit on your workstation, the code will be deployed to your server!
In fact, this is the mechanism I utilize for my own (hobby) development projects. An example of here, is my own homepage, which is deployed via the system as described above.
The Overall Process
- Study ; The first step… Consider what you want to achieve and what’s life currently like. This might seem as a no-brainer, though you might be surprised how few organisations actually do this.
- RFI ; So you have a great idea? Fantastic! Now compare this with what is currently seen as industry standards and what are common solutions positioned by vendors. My advice here is not to differ too much from the ongoing standards, unless this is really ground breaking or market differentiating for you. Though, in most cases, you are just looking to keep your business running. In the latter case, keep as close to the standard as possible.
- RFP/RFQ ; So we know what we want, and what is possible at this point in time by the market. Let’s select our vendors from who we wish a clear-cut proposal. We’ll go more in detail about this phase later on… So don’t worry. 🙂
- Project ; Once the selection is done and contract negotiations are (near) closed, the project can start. This usually starts with a due diligence by the vendor to check if the assumptions / constraints are still valid.
- Operations ; A lot of people think that operations stops during this project. The reality is far from it, and that’s actually common sense! We do projects to enhance our operational baseline, but the latter is a moving target. We cannot freeze our business for half a year! So be aware of this…
The first step before any project should be a “study”. Do a requirements analysis, update your views on the operational baseline and define the target flag of what you want to reach. Now you can do a fit-gap analysis and see what needs to be done. If the entire matter is way to big… Slice it into smaller / manageable chunks. In the past, we often saw “big bang”-projects which have shifted towards “Roadmaps”. In a Roadmap, the road towards the end goal is mapped via smaller / more realistic paths (projects). The conjunction of all these projects ensure that you reach your path. Though where it might be possible to enter all these projects into one RFP, in most cases it might be more interesting to spread them as your operational baseline is (with due reason!) a moving target.
Your job is mostly focussed to serving your internal business processes. It is not wrong to say that you are not an expert in the sector you want to purchase from. This is not something to be ashamed of! Though, be aware that your vendor IS an expert in the matter. During the “RFI” (Request for Information”) you are going to study the relative sector from which you are looking to acquire services/products. Research into the products and do not be shy to invite vendors over to discuss their products. Learn to know their (dis)advantages and how they can serve your business. In the end… always translate certain “features” / “technologies” into basic requirements. For instance ; IT Storage projects revolve around “capacity”, “performance”, “availability” & “integration”. Thin provisioning, snapshotting, deduplication, … all revolve around “capacity”. So do not be fooled by the nice “bling bling” that vendors portray and search for the essence of what you want to achieve. During this round, you will also define your list of requirements and selection criteria! So be sure to look for the elements that should compose these requirements/criteria.
- Start-up ; Invite the vendors to take part and ask them to confirm. After receiving confirmations, send the RFP to all vendors at the same time.
- Round One ; During the first round, you will allow the vendors some time (typically one to two weeks) to process the RFP. At the end of that period, they will need to have sent all their answers to you. You will process these and provide all vendors with a list of all questions & answers. After which, you will allow them again a given period to adjust their proposal to fit these answers. After the deadline, you will do a “downselect” of the vendors to reach the number of vendors you want in round two.
- Round Two ; When going through the answers of round one, you will notice that there are fundamental differences between vendors. Now you will adjust your requirements to align all the vendors towards one target. In addition, you will invite the vendors to explain their proposals into more detail. This will give you a more profound insight into the reality of things. At the end of this round, you will once again to a downselect to reach the last contestants (typically two or three).
- Last Round ; At the beginning of the last round, be sure to provide the remaining vendors with a clear-cut baseline that everyone should meet. Now you do not want any structural differences between the parties anymore where the main focus will be around meeting the target and pricing. Clearly indicate that this should be their “Best And Final Offer” (“BAFO”), which will be presented at CxO level. At the end, choose the party which ranks the highest in relation to your selection criteria.
- Contract negotiations ; After the selection, contract negotiations will start. In some cases, an “LOI” (“Letter of Intent”) will be signed to create a non-linear relation between the contract negotiations and the project start.
- Project Start ; The project will start with a due diligence; Here an investigation will be done by the vendor to check if all the assumptions made (and agreed upon) are valid. After which the project will kick-off!
Be aware that these kind of processes can take up to half a year! So be sure to initiate them with ample time left before your deadline. Also be aware that these things will have a delay and in most cases this is caused by yourself! You still have your regular job to do… and you will get questions that you did not consider and need time to analyze.
RFP/RFQ Document Contents
So how should a typical RFP/RFQ document look?
- Management Summary ; Create a one-pager for executives from the vendors to read through.
- Context ; Why do you launch this RFP/RFQ? Provide an insight into your way of working/environment. How does this project interact with it?
- Timing ; Setup a clear timing table. Each phase should have a clear deadline… An RFP/RFQ is a project so be sure to manage it like a project. This is also important for the vendors to allocate resources towards the process of answering the proposal. It is in your best interest to ensure that they can prepare themself properly.
- Selection Criteria ; Always use (and communicate!) selection criteria. You, and the vendors, should know how you will quote their proposals and make the final selection. Be ware that these will become the core driver for the proposals! If you hand out more than 50% on price, then you will get skimmed down offers.
- Requirements & Product/Service/Project Definition ; Apart from the selection criteria, also be aware that the vendor will provide you the most slim answer to meet your requirements. So if you didn’t define it, you will not receive it! Do not assume anything… This might again look like a no-brainer, though… 😦
- Constraints ; Actually, these can also be considered requirements… Yet be sure to state that a vendor should take certain constraints into account. Do you require a certain transition / honeymoon period? Do their employees need to have NATO-clearance, …
- Pricing Table ; You do not want all vendors to provide their own pricing table… You will not be able to compare apples with oranges. So provide your own pricing table and adjust it according to the feedback from each round. In fact, your RFI phase should have already provided you with ample information to create a pretty stable pricing sheet.
Check out the following posts, they will surely help you!
For those who also use a Zotac GT 430 (under Ubuntu) ;
- The following channel was a succes :
aplay -Dplughw:1,9 /usr/share/sounds/alsa/Front_Center.wav
- Added “load-module module-alsa-sink device=plughw:1,9” to /etc/pulseaudio/default.pa
- Changed “/usr/share/alsa/alsa.conf
William Li presents a new way to think about treating cancer and other diseases: anti-angiogenesis, preventing the growth of blood vessels that feed a tumor. The crucial first (and best) step: Eating cancer-fighting foods that cut off the supply lines and beat cancer at its own game.
Check out the following article “Economic Theory and IT” at “Pivot Point”.
It’s a nice comparison between the old ways in the Soviet Union and the reluctance to change within our current IT market.