In­ter­net Per­for­mance is Key

To en­sure the suc­cess of the smart cities pro­ject, it is es­sen­tial to in­vest in build­ing a strong foun­da­tion that can sup­port the in­creased de­pen­dence on the In­ter­net in­fra­struc­ture in the coun­try.

Voice&Data - - FRONT PAGE - Martin Ryan (The au­thor is VP and Man­ag­ing Di­rec­tor Asia Pa­cific, Dyn) vndedit@cy­berme­dia.co.in

The stakes for the govern­ment and all so­lu­tion and ser­vice providers are sky­rock­et­ing. Just like eCom­merce busi­nesses have been strug­gling with in­ad­e­quate In­ter­net in­fra­struc­ture and poor con­nec­tiv­ity across devices, smart cities too are ex­pected to grap­ple with sim­i­lar is­sues that could sig­nif­i­cantly slow down their cre­ation.

With this back­ground in mind, In­ter­net per­for­mance be­comes a crit­i­cal el­e­ment in en­sur­ing that mul­ti­ple ser­vices con­nected within smart cities are al­ways reach­able, fast, and se­cure. In­ter­net per­for­mance is an ap­proach to im­prove the avail­abil­ity, se­cu­rity, speed, and cost­ef­fi­cien­cies of your In­ter­net in­fra­struc­ture by pro­vid­ing in­sight into In­ter­net con­di­tions so you can re­spond ef­fec­tively. What this es­sen­tially means is:

1) Al­ways Reach­able: Once im­ple­mented, users will ex­pect au­to­mated ser­vices to be reach­able: 24 hours a day, 7 days a week, 365 and one quar­ter days a year!

Reach­a­bil­ity and avail­abil­ity are closely re­lated, but dif­fer­ent. Reach­a­bil­ity means a user can get to the ser­vice/ web­site over the In­ter­net. Rout­ing and DNS are two key com­po­nents of reach­a­bil­ity.

Avail­abil­ity means the ser­vice/ web­site is ac­tu­ally there (up and run­ning) when a user gets to your web servers!

2) Al­ways Fast: The In­ter­net is con­stantly chang­ing. In the eCom­merce seg­ment, three sec­onds can be the dif­fer­ence be­tween a loyal cus­tomer and a lost cus­tomer. Hence, essentials like the ones men­tioned below are a must:

Im­prove web­site per­for­mance: As ev­ery user’s first ex­pe­ri­ence of the ser­vice will start with mul­ti­ple DNS queries, avoid mak­ing them wait for the ser­vice to load by re­solv­ing DNS queries faster and rout­ing users to the most op­ti­mal end­point for per­for­mance.

Cre­ate a seam­less om­nichan­nel ex­pe­ri­ence:

Whether users are ac­cess­ing the ser­vice from home on their com­put­ers or on the go with their mo­bile devices, en­sure that they al­ways ex­pe­ri­ence the same great per­for­mance.

Stay on top of In­ter­net trends:

Use In­ter­net per­for­mance tools to in­tel­li­gently mon­i­tor and an­a­lyze cur­rent In­ter­net con­di­tions and make im­por­tant in­fra­struc­ture de­ci­sions to im­prove the over­all per­for­mance of the ser­vice.

Re­main con­sis­tent across bor­ders:

Ge­olo­ca­tion load bal­anc­ing al­lows to route users based on their lo­ca­tion (for ex­am­ple, coun­try, state, or prov­ince). With a global net­work, users can ex­pect to re­ceive the same per­for­mance from the ser­vice whether they’re at home or trav­el­ing abroad.

3) Al­ways Se­cure: A se­cu­rity breach is ab­so­lutely un­ac­cept­able and can lead to a loss of user con­fi­dence in the ser­vices and ul­ti­mate the ser­vice providers.

Tra­di­tion­ally, en­ti­ties have fo­cused their se­cu­rity ef­forts on se­cur­ing their net­work or dat­a­cen­ter perime­ter with se­cu­rity in­fra­struc­ture such as fire­walls and in­tru­sion preven­tion sys­tems (IPSes). How­ever, very lit­tle fo­cus has been di­rected to­ward ex­tend­ing se­cu­rity be­yond—or out­side—the fire­wall which is where the point of en­try for the breach usu­ally is.

Avoid ‘Death by Retry’

When we are de­pen­dent on ser­vices that are out of our con­trol, we have to be con­scious of two things: They may stop work­ing at any point; we will have no con­trol what­so­ever over when they will start work­ing again. There­fore, we have to ar­chi­tect sys­tems to han­dle this fail­ure.

From a smart cities per­spec­tive, once a fail­ure state is known, it would be es­sen­tial to share that knowl­edge across any el­e­ments of the sys­tem that de­pend on that ser­vice and put in place a mea­sured pol­icy for at­tempt­ing re­tries. It is best to not cre­ate a ‘death by retry’ sit­u­a­tion where the sys­tem is brought down by con­stant at­tempts to con­nect to an un­avail­able sys­tem.

A good ar­chi­tec­tural prac­tice is to route all re­quests through a cen­tral point of con­nec­tion. If the func­tion­al­ity pro­vided by the third-party sys­tem is key, then con­sider hav­ing a re­place­ment sys­tem in place and au­to­mat­i­cally failover to it.

An­other op­tion is to cap­ture all the de­tails of the re­quest for pro­cess­ing off­line when the sys­tem re­turns. This is valid for sys­tems for pay­ment pro­cess­ing or ap­point­ment book­ings.

The Last Word

As smart cities evolve, there are two im­por­tant fac­tors that need to be con­sid­ered. One is the phys­i­cal cre­ation of the smart city with its in­fra­struc­ture, em­ploy­ment, hous­ing, etc. The se­cond is how it will be self-suf­fi­cient, gen­er­at­ing its own (pros­per­ity) econ­omy and wealth—here it will be im­por­tant to en­sure the In­ter­net in­fra­struc­ture is de­signed not for to­day but for the fu­ture and it is with the use of ag­nos­tic sup­pli­ers. The In­ter­net in­fra­struc­ture is what will be the con­nec­tion of peo­ple, con­tent, and com­merce within the city, as well as the rest of In­dia and the world.

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.