How to upload the security certificate and terminate SSL at AWS ELB for your website

As most of AWS users are well aware that ELB can be an SSL termination point for the incoming traffic to your website, today I will show step by step how  you can build, upload and save the SSL certificate on an ELB.
There are three parts to doing this:

Step 1: Build

As most of SSL certs of a corporation is handled by a dedicated team which maintains and creates the signed and verified certificate, they usually provide the certs on asking in standard format. They basically provide three things

• A ".crt" extension file say acme.com.crt

 Sample crt file

-----BEGIN CERTIFICATE-----

jytdlhdxcz77dfd67idfefhend,

iuhfdfjhw8094kmdlksj88d9

.

.

.

kjdskjshkdshdskhsa7rri23l;j

-----END CERTIFICATE-----

• A ".key" extension file say acme.com.key

Sample key file

-----BEGIN RSA PRIVATE KEY-----

Proc-Type: 4,ENCRYPTED

DEK-Info: DES-EDE3-CBC,672767RTE

re87e8eetr7ettewew7

ew68w68ere7e6rewr

.

.

.

yeiurwyireuyrere8987

-----END RSA PRIVATE KEY-----

• And a password string for it('password')

On the other hand AWS needs these certificates as 'pem' encoded. so first step is to convert these files into format which AWS ELB needs. To do that you need to have openssl installed which on linux machines is installed by default most of the times but on windows you may have to install it.

After installing you have to generate two pem encoded files as ELB needs, one public another private.

To generate public file use the following command(If prompted for password provide the password as mentioned above)

openssl x509 -inform PEM -in acme.com.crt > public.pem

To generate the private file use the following command(If prompted for password provide the password as mentioned above)

openssl rsa -in acme.com.key -text > private.pem

In private.pem file you will have a lengthy certificate chain which is optional in ELB but at the end the file would look something like this.

-----BEGIN RSA PRIVATE KEY-----

yre7tet78etew8euyue

ew68w68ere7e6rewr

.

.

.

,n,xn,xcmnc7v7cyc7nn

-----END RSA PRIVATE KEY-----

The public.pem file will most likely remain same and would most likely look like your .crt file but whatever the result your sample public.pem would looks like this

-----BEGIN CERTIFICATE-----

jytdlhdxcz77dfd67idfefhend,

iuhfdfjhw8094kmdlksj88d9

.

.

.

kjdskjshkdshdskhsa7rri23l;j

-----END CERTIFICATE-----

 Step 2: Upload and Save

On the AWS console navigate to ELB page and click on ELB where you want to apply this certificate. On the bottom pane click on Listener tab(see image) and click on change link(as marked by arrow)

On clicking the change or upload button you would see the a modal where you would copy paste the content of the private.pem and public.pem file we generated (see attached image) In private.pem just copy paste the bottom part starting with -----begin private key-----

 This two step process will terminate your ssl at ELB and will provide enable your website to be secure on https protocol

Sid
http://dailytechscape.com

SQL vs NO SQL ... Concluded

In this concluding post of SQL vs No SQL technologies I would like to call out various No SQL technologies available in the market place today. I would not go in to SQL as this has been well established and well understood theme. I would also conclude with some use cases of picking up No SQL over SQL or vice-versa.

The three most common operational No SQL db which are used today are Mongo DB, Cassandra and Couch DB. There are a lot more No SQL dbs available and I would point the readers to following link by Kristof Kovacs who does a pretty good job of outlining them for reading and understanding all of them in detail instead of trying to repeat it here.
http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Regarding some specific use cases of No SQL vs SQL, I think No SQL with all its advantages as outlined in previous posts addresses most of use cases for general use and in my opinion is prefered over SQL technologies. But there are some very specific uses cases and industries where traditional DBs are still preferred. One such use case is around heavy transactional applications such as banking or financial transaction applications. The ACID properties of SQL dbs as discussed in my previous post is very important to such applications and the out of box 2 phase commit protocol and rollback makes SQL stand out. But as I said most of other use cases can be addressed better by No SQL dbs.

SQL or No SQL- Operational vs Analytical

Happy new year to you all!

Last time we discussed what is Big data and how it relates to No SQL. This time I am going to talk about two different kind of data storage and retrieval requirements: Operational and Analytical.

Operational and analytical workloads for Big Data present opposing requirements and systems have evolved to address their particular demands separately and in very different ways. Operational workloads are supposed to be highly concurrent, low latency, very selective. While analytical workloads are query intensive looking at a huge data set. 
No SQL DBs mainly help on operational side of the spectrum.

Operational vs Analytical overview

	OPERATIONAL	ANALYTICAL
Latency	1 ms - 100 ms	1 min - 100 min
Concurrency	1000 - 100,000	1 to 10
Access Pattern	Writes and Reads	Reads
Queries	Selective	Unselective
Data Scope	Operational	Retrospective
End User	Customer	Data Scientist
Technology	NoSQL	MapReduce, MPP Database

Next post I will try to conclude the SQL-  NO SQL  topic

SQL or No SQL- Big Data angle

Continuing from my previous post lets look at what is big data and how modern No SQL DBs help in capturing this data.
Big data as name suggests is vast amount of data, Data which is measured in TBs or PBs. With the cost of storage and network drastically reduced over past few years and expansion of cloud has helped companies to capture as much data as they can. The new paradigm is "Just collect it" which means just gather any and all kinds of data we will figure out later how to slice and dice it and how to use it for analysis.  This 'just collect it' principal is also a factor in driving No SQL dbs as most of this data is un-structured or semi structured like raw text in form of tweets, user comments or data like log files etc.
The three important aspect in fulfilling the business needs of  big data is Volume(Amount of data), Velocity(speed of storing and retrieving) and Variety(types of structured, unstructured data).
Business needs for big data can broadly be classified into two: Operational and Analytical

I will talk about more in detail about how these two needs are solved by technology products and how NO SQL helps in next post.

SQL or No SQL- Basics

I am gonna write a multi-part series on this topic as it is a vast topic to cover. I want to start with basics and then dig deep on technologies, architecture choices, security etc.

Basics:

SQL: I think every developer, architect has used this type of schema in some shape of form. Examples of such dbs are MYSQL, Oracle, MS SQL Server,  Sybase etc. They are better called as RDBMS or Relational databases. The primary idea of such dbs are ACID properties.

A-Atomicity,
C- Consistency
I- Isolation
D-Durability

In short they are transactional and relational in nature allowing SQLs to be written on them which allows joins, sub-queries on multiple tables.

No SQL: No SQL dbs have become popular in last 7-10 years and they are mainly as name suggest non RDBMS dbs. They don't adhere to strict relational properties and are more like key value kind of storage. The reason for their popularity has been the growth in data and with huge data growth the RDBMS has lot of issues in scaling and becoming distributed. They have to keep the ACID properties in check while they grow and scale out and become bottlenecks for fast applications. Hence No SQL: Example of such dbs are MongoDB, Cassandra, CouchDB etc.
The guiding property for such DBs is CAP theorem

• C​onsistency(Eventually)
• A​vailability
• tolerance to network P​artitioning

I will cover little more advanced stuff about No SQL in next writeup.

Data accuracy and trends- How to measure the anomaly and resolve it

There is always a disconnect between applications team and Data-warehouse teams in an enterprise about the accuracy of the data from source systems. Data team has its own arguments with their own merits as to why they need accurate and predictable data from source systems and applications team have their own as to why it cant always be 100%.

Primary reason for application team to have problem providing 100% accurate data is the continuous evolution of business applications and systems and ongoing bugs  in applications which tend to create anomaly in the data. Data team has its argument that unless they get accurate data its hard to do meaningful analysis and build reports on it.

There are some ideas in my mind how this gap can be bridged if not eliminated totally:

1. How much accuracy is a good level of accuracy: Lets face it that unless you are in some kind of transactional application such as banking application you will always have to rely on un predictable and random end user behavior. This aggravates when its a B2C application where primarily data is generated by end user behavior and interaction with the application. There will always be edge cases, forget the bugs in application( which would also never go to  zero). that means its a good point for two teams to get together and define the business level adherence to the accuracy of the data.
2. Fix it by process: Another way to reduce data in accuracy in an ever evolving business application is to have a tighter integration of data team with app development team in their development process. Its always a good idea to have these two teams communicate to each other on an ongoing basis of up coming development plan and changes to the application.
3. QA it!. Another way to reduce data gaps introduced by bugs in any release of an application to have QA plan and execute test plans with reporting teams input. Any good QA org should build test cases keeping data needs in mind and with data teams input.

Please provide other ideas if you may have.

Five basic and fundamental SEO tips as Google recommends and wants it

Here are five basic tips which I use for all my websites and they are SEO 101 tips recommended by Google

1. Define a good title on your website which reflects the website's  nature and content: This is what google uses to put as heading in its search result display. e.g. for dailytechscape.com   <title>Relevant and intelligently picked daily technology news and articles. It cuts the noise and shows most relevant news item in the tech world. </title>
2. Use good and relevant domain name and keep your url structures also user readable with descriptive text. e.g. dailytechscape.com/daily-technology-news
3. Use meta tags as good description on your site. Google uses this tag to show detail about your site in its search result list e.g <meta name="description" content="Technology, News, Landscape, hand picked and relevant daily technology news, news about startups, daily technical landscape">
4. If possible prepare sitemap for your site and keep the site structure simple and easy to understand for googlebot to navigate and crawl
5. Final and the most important basic concept. Keep your site with good, relevant content and keep it updated and manage it actively.