4 INNOVATIVE WAYS TO USE AMAZON WEB SERVICES

December 9, 2017 Leave a comment

The most successful users of Amazon Web Services (AWS) don’t use it like traditional infrastructure offered on a pay-as-you-go basis. Instead, they study AWS and then think about how they can use its services and characteristics to design new offerings that were impossible with traditional infrastructure.

Here are some innovative ways to use AWS:

  • Design an application that supports enormous numbers of users. The effectively unlimited scale of resources that AWS provides makes it possible, for the first time in the history of computing, to build applications that can support unlimited user populations. This enables applications like Pinterest to start and scale; what can scale do for you?

  • Participate in “The Internet of Things.” One way of saying it is “software is eating the world.” Another is that everything is becoming a computing device — your watch, your car, your front door lock. The “IoT,” as it’s known, will generate huge amounts of data and network traffic. Use AWS to create an application that delivers a new service or analyzes existing ones.

  • Combine a number of services into a new application. Every application and service is now becoming API-enabled, making it easy to aggregate existing services into a new application. Combine a weather service and a personal health service to enable people to calculate how much Vitamin D3 they’re going to get today. Use AWS to host your application, secure in the knowledge that it can support you whether your application traffic is tiny or huge.

  • Integrate AWS services into your application to make it more powerful. You can use Simple Email Service (SES) to notify users of an important event. You can use Elastic Transcoder to enable user video uploads to make your application functionality richer. There are tons of AWS products to choose from — use as many as you can.

Thanks to Golden

Advertisements
Categories: Uncategorized Tags: ,

5 THINGS THAT AMAZON WEB SERVICES CAN AND CAN’T DO

December 9, 2017 Leave a comment

A sure recipe for disappointment is to expect more from Amazon Web Services (AWS) than it can deliver. While AWS is a rich collection of services that are available in effectively unlimited scale, it’s important to understand that there are a number of things AWS can and cannot do:

  • AWS cannot make your legacy application “cloud-based.” Legacy applications have typically been designed for stable loads with static hardware infrastructure. They will probably work in AWS, but they won’t magically become cloud applications.

  • AWS can support highly scalable applications. Think of AWS as offering infinite capacity. All those applications you had trouble with because they outgrew predicted user load, storage use, or network traffic? No problem anymore with AWS. Amazon provides the resource, you provide the application load.

  • AWS cannot make your application failure-proof. Amazon designed AWS based on the notion that “everything fails all the time.” While AWS is designed to be highly resilient to resource failure, that doesn’t mean your application can’t fail — it just means that you have the ability to make your application more robust, if you leverage AWS application design principles.

  • AWS can make it cost less to run your application. Because Amazon provides AWS on a usage-based cost, if you design your application to follow the “down and off” principle of using only what you need and then skedaddling, you can typically save a lot of money compared to the traditional model of resource cost, where you pay up front for resources.

  • AWS cannot make your application secure for you. In cloud computing environments, security is a shared responsibility. Amazon takes on security responsibility for what it provides — the computing environment — while you take on security responsibility for what you provide — application software components. If you don’t do a good job managing your application’s security, there’s nothing Amazon can do to make it secure.

Thanks to Golden

Categories: Uncategorized Tags: ,

Causes of war

July 19, 2015 Leave a comment

There can be only 2 causes of war

1. For Land

This is the most happening one and there are millions of cases we can compare for the war because of land. Even now as well.

2. For Lady

This was happening when the civilizations were growing and most of the examples date before Christ.

This can be rooted from the historic epics from India. One of them has been fought for Lady (Sita) and the other has been fought for Land (Hastinapura).

Just to have stable population, god could have thought of reducing this from 2 to 1. He has no option to reduce the land volume, but can keep tab on Lady’s beauty. So, he might have thought of slightly reducing beauty so that the second option can be kept on control. He wished Cleopatra should be the last one, thus making her suicide ~30BC.

– This is truly a thought and nothing intentional to hurt anybody.

Thanks,

Yuvaraj

Yuvahere.com

Categories: History, Thought

Interesting fact in Google site

April 3, 2015 Leave a comment

There is another jaw dropping fact in Google website.

Now both the below links goes to same page, try this and shout

google.com

com.google

Will catch you soon.

Thanks,

Yuvaraj

Categories: Miscellaneous

Design concepts MANTRA – Always keep handy

March 25, 2015 Leave a comment

There are several design principles which are around us. All focussing on these key principles.

1. Separation of Concerns: Don’t overlap your functionality and keep the functions in distinct chunks

2. Single Responsibility Principle: Each component should be responsible for handling a single feature.

3. Principle of Least Knowledge (Law of Demeter – LoD): A component should not know about the internal details of other components.

4. Don’t repeat Yourself (DRY): The functionality or logic should not be repeated in any other component.

5. Minimise Upfront Design: Only design for what is necessary and don’t exaggerate the services and over design the concepts. This might lead to complexity and excess cost.


 

Architectural Styles – A consolidated view

1. Client/Server:  Segregates the system into two applications, where the client makes requests to the server.
2. Component-Based Architecture: Decomposes application design into reusable functional or logical components that expose well-defined communication interfaces.
3. Domain Driven: Design An object-oriented architectural style focused on modeling a business domain
and defining business objects based on entities within the business domain.
4. Layered Architecture: Partitions the concerns of the application into stacked groups (layers).
5. Message Bus: An architecture style that prescribes use of a software system that can receive and send messages using one or more communication channels, so that applications can interact without needing to know specific details about each other.
6. N-Tier / 3-Tier: Segregates functionality into separate segments in much the same way as the layered style, but with each segment being a tier located on a physically separate computer.
7. Object-Oriented: A design paradigm based on division of responsibilities for an application or system into individual reusable and self-sufficient objects, each containing the data and the behaviour relevant to the object.
8. Service-Oriented Architecture (SOA): Refers to applications that expose and consume functionality as a service using contracts and messages.

Thanks,

Yuva

http://Yuvahere.com

Categories: Architecture

CSRR – Change Save Refresh Result – in ASP.NET 5.0

March 25, 2015 Leave a comment

There is one step leap in .NET framework.

This new outburst of change-save-refresh-result (CSRR) will change the way the developers tie code.

Dynamite Scott has introduced this dynamic feature to our community.

CSRR

 

Thanks,

Yuva

Categories: SQL and .NET Blog

Big question to Mark??

January 17, 2013 Leave a comment

Hello Mark,

The domain “www.facebook.com” was

Created on……………….: 1997-03-28.
Expires on………………..: 2020-03-29.
Record last updated on..: 2012-09-28.

Big Question??
You have officially launched this site on Feb’2004, but the domain was created on 1997.

That year, you could only be 12 years old. Have you purchased this domain at the age of 12??

If not, then who was the actual owner of this “Registered (R)” name “Facebook”??

-Yuva